All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Christoph Lameter <clameter@sgi.com>
Cc: Hugh Dickins <hugh@veritas.com>, Nick Piggin <npiggin@suse.de>,
	linux-kernel@vger.kernel.org, pj@sgi.com
Subject: Re: Pagecache: find_or_create_page does not call a proper page allocator function
Date: Tue, 24 Apr 2007 14:24:11 -0700	[thread overview]
Message-ID: <20070424142411.95462085.akpm@linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0704241354470.13382@schroedinger.engr.sgi.com>

On Tue, 24 Apr 2007 13:58:35 -0700 (PDT) Christoph Lameter <clameter@sgi.com> wrote:

> On Tue, 24 Apr 2007, Andrew Morton wrote:
> 
> > > Then I think we should disable page migration for allocations that do not 
> > > allow access to the policy zone. That would fix it.
> > 
> > Can't we use mapping_gfp_mask() when allocating the destination page?
> 
> There is no point in migrating something if you cannot reach the 
> destination. If the policy zone is not allowed by an allocation then the 
> page cannot be migrated because (on 32 bit NUMA) there is only a single 
> ZONE_NORMAL on the system. A different node requires a HIGHMEM allocation!

don't care really.  If we're allocating a page for an address_space, we
should be using its allocation mask.  As I said, we might add more things in
the future.

If in so doing the user pointlessly wastes some CPU cycles in one weird
case, it doesn't matter a lot.

> > It would be better to do so, really.  Who knows, mapping_gfp_mask() might
> > be extented in the future to say "I want GFP_NOIO" or something.  Or a
> > filesystem might specify GFP_KERNEL for regular pagecache pages or
> > whatever.
> 
> Hmmm..... How about a VM_DONTMIGRATE flag instead? That would be easy to 
> check and could be set by a device that must have all pages of the address
> space conforming to the gfp mask.
> 
> Or more general
> 
> VM_STRICT_ALLOC?

ug.  That's special-casing the blockdev pagecache peculiarity when someone
mmaps it.  It'd be better to stick with the existing interfaces and
conventions: the address_space gets to dictate how is pages are allocated.

> > Generally, the interface is "address_space tells core kernel how to
> > allocate its pages", and to be nice we should honour that in all places
> > where we allocate a page for an address_space.
> > 
> > If we'd had any brains we would have implemented this function as an
> > address_space_operations callback, but we don't so we didn't.
> 
> We have enough flags I think.

mapping_gfp_mask if a pretty foul thing.  Adding

	struct page (*alloc_page)(struct address_space *mapping);

to address_space_operations would be a quite nice cleanup.

But I ain't taking cleanups at present.

<goes back to working on a critical 2.6.21 bug>

  reply	other threads:[~2007-04-24 21:24 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-23 21:11 Pagecache: find_or_create_page does not call a proper page allocator function Christoph Lameter
2007-04-23 21:29 ` Andrew Morton
2007-04-23 21:37   ` Christoph Lameter
2007-04-23 22:33   ` Christoph Lameter
2007-04-23 22:42     ` Christoph Lameter
2007-04-23 22:42     ` Andrew Morton
2007-04-24 13:09       ` Hugh Dickins
2007-04-24 17:11         ` Andrew Morton
2007-04-24 19:06           ` Hugh Dickins
2007-04-24 19:55             ` Christoph Lameter
2007-04-24 20:16               ` Hugh Dickins
2007-04-24 20:30                 ` Christoph Lameter
2007-04-24 20:42                   ` Andrew Morton
2007-04-24 20:44                     ` Christoph Lameter
2007-04-24 20:53                       ` Andrew Morton
2007-04-24 20:58                         ` Christoph Lameter
2007-04-24 21:24                           ` Andrew Morton [this message]
2007-04-24 21:28                             ` Christoph Lameter
2007-04-24 17:38         ` Christoph Lameter
2007-04-24 17:45           ` Hugh Dickins
2007-04-24 17:48             ` Christoph Lameter
2007-04-24 17:51             ` Andrew Morton
2007-04-24 17:56               ` Christoph Lameter
2007-04-24 17:45         ` Christoph Lameter
2007-04-24 18:53           ` Hugh Dickins
2007-04-24 19:34             ` Christoph Lameter
2007-04-24 19:49               ` Andrew Morton
2007-04-24 19:59                 ` Christoph Lameter
2007-04-24 20:10                   ` Andrew Morton
2007-04-24 20:12                     ` Christoph Lameter
2007-04-24 20:20                       ` Andrew Morton

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=20070424142411.95462085.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@suse.de \
    --cc=pj@sgi.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.