From: Hugh Dickins <hugh@veritas.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Rohland <hans-christoph.rohland@sap.com>,
Nick Piggin <npiggin@suse.de>,
linux-kernel@vger.kernel.org
Subject: [PATCH 8/9] tmpfs: radix_tree_preloading
Date: Tue, 18 Dec 2007 22:05:19 +0000 (GMT) [thread overview]
Message-ID: <Pine.LNX.4.64.0712182204210.27165@blonde.wat.veritas.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0712182144370.26235@blonde.wat.veritas.com>
Nick has observed that shmem.c still uses GFP_ATOMIC when adding to page
cache or swap cache, without any radix tree preload: so tending to deplete
emergency reserves of memory.
GFP_ATOMIC remains appropriate in shmem_writepage's add_to_swap_cache:
it's being called under memory pressure, so must not wait for more memory
to become available. But shmem_unuse_inode now has a window in which it
can and should preload with GFP_KERNEL, and say GFP_NOWAIT instead of
GFP_ATOMIC in its add_to_page_cache.
shmem_getpage is not so straightforward: its filepage/swappage integrity
relies upon exchanging between caches under spinlock, and it would need a
lot of restructuring to place the preloads correctly. Instead, follow
its pattern of retrying on races: use GFP_NOWAIT instead of GFP_ATOMIC in
add_to_page_cache, and begin each circuit of the repeat loop with a sleeping
radix_tree_preload, followed immediately by radix_tree_preload_end - that
won't guarantee success in the next add_to_page_cache, but doesn't need to.
And we can then remove that bothersome congestion_wait: when needed,
it'll automatically get done in the course of the radix_tree_preload.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
---
mm/shmem.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
--- tmpfs7/mm/shmem.c 2007-12-06 18:11:26.000000000 +0000
+++ tmpfs8/mm/shmem.c 2007-12-06 19:20:29.000000000 +0000
@@ -901,12 +901,16 @@ found:
error = 1;
if (!inode)
goto out;
+ error = radix_tree_preload(GFP_KERNEL);
+ if (error)
+ goto out;
+ error = 1;
spin_lock(&info->lock);
ptr = shmem_swp_entry(info, idx, NULL);
if (ptr && ptr->val == entry.val)
error = add_to_page_cache(page, inode->i_mapping,
- idx, GFP_ATOMIC);
+ idx, GFP_NOWAIT);
if (error == -EEXIST) {
struct page *filepage = find_get_page(inode->i_mapping, idx);
error = 1;
@@ -931,6 +935,7 @@ found:
if (ptr)
shmem_swp_unmap(ptr);
spin_unlock(&info->lock);
+ radix_tree_preload_end();
out:
unlock_page(page);
page_cache_release(page);
@@ -1185,6 +1190,16 @@ repeat:
goto done;
error = 0;
gfp = mapping_gfp_mask(mapping);
+ if (!filepage) {
+ /*
+ * Try to preload while we can wait, to not make a habit of
+ * draining atomic reserves; but don't latch on to this cpu.
+ */
+ error = radix_tree_preload(gfp & ~__GFP_HIGHMEM);
+ if (error)
+ goto failed;
+ radix_tree_preload_end();
+ }
spin_lock(&info->lock);
shmem_recalc_inode(inode);
@@ -1266,7 +1281,7 @@ repeat:
set_page_dirty(filepage);
swap_free(swap);
} else if (!(error = add_to_page_cache(
- swappage, mapping, idx, GFP_ATOMIC))) {
+ swappage, mapping, idx, GFP_NOWAIT))) {
info->flags |= SHMEM_PAGEIN;
shmem_swp_set(info, entry, 0);
shmem_swp_unmap(entry);
@@ -1280,10 +1295,6 @@ repeat:
spin_unlock(&info->lock);
unlock_page(swappage);
page_cache_release(swappage);
- if (error == -ENOMEM) {
- /* let kswapd refresh zone for GFP_ATOMICs */
- congestion_wait(WRITE, HZ/50);
- }
goto repeat;
}
} else if (sgp == SGP_READ && !filepage) {
@@ -1338,7 +1349,7 @@ repeat:
shmem_swp_unmap(entry);
}
if (error || swap.val || 0 != add_to_page_cache_lru(
- filepage, mapping, idx, GFP_ATOMIC)) {
+ filepage, mapping, idx, GFP_NOWAIT)) {
spin_unlock(&info->lock);
page_cache_release(filepage);
shmem_unacct_blocks(info->flags, 1);
next prev parent reply other threads:[~2007-12-18 22:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-18 21:55 [PATCH 0/9] tmpfs: towards unionfs and memcgroups Hugh Dickins
2007-12-18 21:57 ` [PATCH 1/9] tmpfs: move swap_state stats update Hugh Dickins
2007-12-18 21:59 ` [PATCH 2/9] tmpfs: shuffle add_to_swap_caches Hugh Dickins
2007-12-19 1:55 ` Nick Piggin
2007-12-18 22:00 ` [PATCH 3/9] tmpfs: move swap swizzling into shmem Hugh Dickins
2007-12-18 22:01 ` [PATCH 4/9] tmpfs: allow filepage alongside swappage Hugh Dickins
2007-12-18 22:51 ` Erez Zadok
2007-12-19 0:30 ` Hugh Dickins
2007-12-18 22:02 ` [PATCH 5/9] tmpfs: allocate on read when stacked Hugh Dickins
2007-12-18 22:03 ` [PATCH 6/9] tmpfs: make shmem_unuse more preemptible Hugh Dickins
2007-12-18 22:04 ` [PATCH 7/9] tmpfs: open a window in shmem_unuse_inode Hugh Dickins
2007-12-18 22:05 ` Hugh Dickins [this message]
2007-12-19 6:50 ` [PATCH 8/9] tmpfs: radix_tree_preloading Nick Piggin
2007-12-18 22:06 ` [PATCH 9/9] tmpfs: fix shmem_swaplist races Hugh Dickins
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=Pine.LNX.4.64.0712182204210.27165@blonde.wat.veritas.com \
--to=hugh@veritas.com \
--cc=akpm@linux-foundation.org \
--cc=hans-christoph.rohland@sap.com \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
/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
all inboxes | Powered by JetHome®