Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH] Compound page overhaul | Date | Tue, 23 Nov 2004 17:24:33 +0000 |
| |
William Lee Irwin III <wli@holomorphy.com> wrote: > The MMU-less code appears to assume the refcounts of the tail pages > will remain balanced, and elevates them to avoid the obvious disaster. > But this looks rather broken barring some rather unlikely invariants.
I had to fix it to make it work, but what's currently lurking in Andrew's tree seems more or less correct, just not necessarily safe.
> I presume the patch is backing that out so refcounting works properly, or in > the nomenclature above (for which there is a precedent) makes the refcount a > superpage property uniformly across MMU and MMU-less cases.
My patch drops the old !MMU page refcount wangling stuff in favour of using compound pages, which seem to work just as well.
> It's unclear (to me) how the current MMU-less code works properly, at > the very least.
For the most part it's down to two !MMU bits in page_alloc.c - one sets all the refcounts on the pages of a high-order allocation, and the other decrements them all again during the first part of freeing.
This works okay with access_process_vm() as is because that pins the mm_struct semaphore too; but it's also possible that something else does or will pin a secondary page and then drop the semaphore.
> It would appear to leak memory since there is no obvious guarantee the > reference to the head page will be dropped when needed, though things may > have intended to free the various tail pages.
Actually, it's more a problem of the "superpage" being freed when the subpages have elevated counts.
> i.e. AFAICT things really need to acquire and release references on the > whole higher-order page as a unit for refcounting to actually work, > regardless of MMU or no.
I agree.
> It may also be helpful for Greg Ungerer to help review these patches, > as he appears to represent some of the other MMU-less concerns, and > may have more concrete notions of how things behave in the MMU-less > case than I myself do (hardware tends to resolve these issues, but > that's not always feasible; perhaps an MMU-less port of a "normal" > architecture would be enlightening to those otherwise unable to > directly observe MMU-less behavior). In particular, correcting what > misinterpretations in the above there may be.
The FRV arch does both MMU and !MMU versions. It's settable by a config option, and I check both.
David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |