Re: [PATCH] Compound page overhaul

[David Howells <dhowells@redhat.com>]

> > 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).

> 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.

> What are you saying?

!MMU linux doesn't actually need to use anything in page[1...N] of a compound
page. The drivers don't. mmap doesn't.

The only thing I know of that comes close to breaking this rule is
access_process_vm(), and that only slightly dents it, and then hammers the
dent out afterwards.

Of course, there may an exception that breaks the rules, but I'm not aware of
one.

David