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
Date: Tue, 23 Nov 2004 08:56:08 -0800 [thread overview]
Message-ID: <20041123085608.3c30aa34.akpm@osdl.org> (raw)
In-Reply-To: <15564.1101228539@redhat.com>
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?
next prev parent reply other threads:[~2004-11-23 22:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-22 13:27 [PATCH] Compound page overhaul David Howells
2004-11-22 14:41 ` William Lee Irwin III
2004-11-22 16:07 ` David Howells
2004-11-22 16:34 ` William Lee Irwin III
2004-11-22 23:54 ` Andrew Morton
2004-11-23 9:18 ` David Howells
2004-11-23 16:11 ` Andrew Morton
2004-11-23 16:48 ` David Howells
2004-11-23 16:56 ` Andrew Morton [this message]
2004-11-23 17:48 ` David Howells
2004-11-23 17:10 ` William Lee Irwin III
2004-11-23 17:24 ` David Howells
2004-11-23 17:46 ` William Lee Irwin III
2004-11-23 17:51 ` David Howells
2004-11-24 14:22 ` Greg Ungerer
2004-11-24 18:03 ` David Howells
2004-11-25 3:37 ` Greg Ungerer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041123085608.3c30aa34.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=dhowells@redhat.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=wli@holomorphy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.