From: David Howells <dhowells@redhat.com>
In-Reply-To: <20041123081129.3e0121fd.akpm@osdl.org> 
References: <20041123081129.3e0121fd.akpm@osdl.org>  <20041122155434.758c6fff.akpm@osdl.org> <11948.1101130077@redhat.com> <29356.1101201515@redhat.com> 
To: Andrew Morton <akpm@osdl.org>
Cc: torvalds@osdl.org, wli@holomorphy.com, hch@infradead.org,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Compound page overhaul 
User-Agent: EMH/1.14.1 SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 23 Nov 2004 16:48:59 +0000
Message-ID: <15564.1101228539@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1707
Lines: 42


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