Messages in this thread | | | Date | Tue, 23 Nov 2004 08:56:08 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] Compound page overhaul |
| |
David Howells <dhowells@redhat.com> wrote: > > > > > ugh, sorry, I'd forgotten that !MMU needs to use the fields inside > > > pages[1]. > > Perhaps I misunderstood what you meant here. I _assumed_ you meant that it > used the bits of pages[1] for compound page metadata - which it now does only > because it's now using compound pages (if only with my patch applied).
I thought that's what you meant ;)
So why did you create a "Compound page overhaul" in the first place? Was it not to address some insufficiency for !MMU?
> > But !MMU really wants to treat that higher-order page as an array of > > zero-order pages, and that requires the usual usage of the fields of > > page[1], page[2], etc. > > That's not really so. For the most part, !MMU linux treats pages identically > to MMU linux, whether those pages are big or small. > > It's only for interprocess userspace access that there's an issue, and the > issue there is, I think, that access_process_vm() wants to pin the page in > place to stop it going away whilst it is being fiddled with. > > Normally, the page is pinned in place by its refcount and/or flags. However, > for compound pages, the refcount in question is really on the first page of > the batch, and so refcount accesses should be directed there, and not to a > secondary page.
The current compound page logic should handle that quite happily, no?
- 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/
| |