Date: Tue, 23 Nov 2004 08:56:08 -0800
From: Andrew Morton <akpm@osdl.org>
To: David Howells <dhowells@redhat.com>
Cc: torvalds@osdl.org, wli@holomorphy.com, hch@infradead.org,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Compound page overhaul
Message-Id: <20041123085608.3c30aa34.akpm@osdl.org>
In-Reply-To: <15564.1101228539@redhat.com>
References: <20041123081129.3e0121fd.akpm@osdl.org>
	<20041122155434.758c6fff.akpm@osdl.org>
	<11948.1101130077@redhat.com>
	<29356.1101201515@redhat.com>
	<15564.1101228539@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1629
Lines: 38

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/