[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0704241841190.19956@blonde.wat.veritas.com>
Date: Tue, 24 Apr 2007 18:45:03 +0100 (BST)
From: Hugh Dickins <hugh@...itas.com>
To: Christoph Lameter <clameter@....com>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Nick Piggin <npiggin@...e.de>, linux-kernel@...r.kernel.org,
pj@....com
Subject: Re: Pagecache: find_or_create_page does not call a proper page
allocator function
On Tue, 24 Apr 2007, Christoph Lameter wrote:
> On Tue, 24 Apr 2007, Hugh Dickins wrote:
>
> > I've not yet looked at the patch under discussion, but this remark
> > prompts me... a couple of days ago I got very worried by the various
> > hard-wired GFP_HIGHUSER allocations in mm/migrate.c and mm/mempolicy.c,
> > and wondered how those would work out if someone has a blockdev mmap'ed.
>
> Hmmm.... These not that critical given that 32 bit NUMA systems are a bit
> rare.
That's true. And everybody but the owners of those systems wish
fervently that they didn't exist ;)
> And if a page is in the wrong area then it can be bounced before I/O
> is performed on it.
I think that much is also true, but not where the problem lies.
Isn't the problem that filesystems using these block devices
expect their metadata to be accessible without kmap calls?
Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists