From: Nick Piggin <npiggin@suse.de>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch 1/2] mm: pagecache allocation gfp fixes
Date: Thu, 27 Nov 2008 11:18:37 +0100 [thread overview]
Message-ID: <20081127101837.GJ28285@wotan.suse.de> (raw)
In-Reply-To: <84144f020811270152i5d5c50a8i9dbd78aa4a7da646@mail.gmail.com>
On Thu, Nov 27, 2008 at 11:52:40AM +0200, Pekka Enberg wrote:
> > - err = add_to_page_cache_lru(page, mapping, index, gfp_mask);
> > + err = add_to_page_cache_lru(page, mapping, index,
> > + (gfp_mask & (__GFP_FS|__GFP_IO|__GFP_WAIT|__GFP_HIGH)));
>
> Can we use GFP_RECLAIM_MASK here? I mean, surely we need to pass
> __GFP_NOFAIL, for example, down to radix_tree_preload() et al?
Updated patch.
--
Frustratingly, gfp_t is really divided into two classes of flags. One are the
context dependent ones (can we sleep? can we enter filesystem? block subsystem?
should we use some extra reserves, etc.). The other ones are the type of memory
required and depend on how the algorithm is implemented rather than the point
at which the memory is allocated (highmem? dma memory? etc).
Some of functions which allocate a page and add it to page cache take a gfp_t,
but sometimes those functions or their callers aren't really doing the right
thing: when allocating pagecache page, the memory type should be
mapping_gfp_mask(mapping). When allocating radix tree nodes, the memory type
should be kernel mapped (not highmem) memory. The gfp_t argument should only
really be needed for context dependent options.
This patch doesn't really solve that tangle in a nice way, but it does attempt
to fix a couple of bugs. find_or_create_page changes its radix-tree allocation
to only include the main context dependent flags in order so the pagecache
page may be allocated from arbitrary types of memory without affecting the
radix-tree. Then grab_cache_page_nowait() is changed to allocate radix-tree
nodes with GFP_NOFS, because it is not supposed to reenter the filesystem.
Filesystems should be careful about exactly what semantics they want and what
they get when fiddling with gfp_t masks to allocate pagecache. One should be
as liberal as possible with the type of memory that can be used, and same
for the the context specific flags.
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
Index: linux-2.6/mm/filemap.c
===================================================================
--- linux-2.6.orig/mm/filemap.c
+++ linux-2.6/mm/filemap.c
@@ -741,7 +741,14 @@ repeat:
page = __page_cache_alloc(gfp_mask);
if (!page)
return NULL;
- err = add_to_page_cache_lru(page, mapping, index, gfp_mask);
+ /*
+ * We want a regular kernel memory (not highmem or DMA etc)
+ * allocation for the radix tree nodes, but we need to honour
+ * the context-specific requirements the caller has asked for.
+ * GFP_RECLAIM_MASK collects those requirements.
+ */
+ err = add_to_page_cache_lru(page, mapping, index,
+ (gfp_mask & GFP_RECLAIM_MASK));
if (unlikely(err)) {
page_cache_release(page);
page = NULL;
@@ -950,7 +957,7 @@ grab_cache_page_nowait(struct address_sp
return NULL;
}
page = __page_cache_alloc(mapping_gfp_mask(mapping) & ~__GFP_FS);
- if (page && add_to_page_cache_lru(page, mapping, index, GFP_KERNEL)) {
+ if (page && add_to_page_cache_lru(page, mapping, index, GFP_NOFS)) {
page_cache_release(page);
page = NULL;
}
next prev parent reply other threads:[~2008-11-27 10:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-27 9:34 [patch 1/2] mm: pagecache allocation gfp fixes Nick Piggin
2008-11-27 9:35 ` [patch 2/2] fs: symlink write_begin allocation context fix Nick Piggin
2008-11-27 11:02 ` KOSAKI Motohiro
2008-11-27 11:14 ` Nick Piggin
2008-11-28 14:37 ` Nick Piggin
2008-11-29 6:35 ` KOSAKI Motohiro
2008-11-27 9:52 ` [patch 1/2] mm: pagecache allocation gfp fixes Pekka Enberg
2008-11-27 10:01 ` Nick Piggin
2008-11-27 10:18 ` Nick Piggin [this message]
2008-11-27 10:28 ` Pekka Enberg
2008-11-27 10:40 ` KOSAKI Motohiro
2008-11-27 18:14 ` Hugh Dickins
2008-11-28 12:04 ` Nick Piggin
2008-12-01 1:18 ` Hugh Dickins
2008-12-01 1:50 ` KAMEZAWA Hiroyuki
2008-12-01 7:39 ` KAMEZAWA Hiroyuki
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=20081127101837.GJ28285@wotan.suse.de \
--to=npiggin@suse.de \
--cc=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@cs.helsinki.fi \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).