From: Hugh Dickins <hugh@veritas.com>
To: Erez Zadok <ezk@cs.sunysb.edu>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Pekka Enberg <penberg@cs.helsinki.fi>,
linux-kernel@vger.kernel.org
Subject: [PATCH 1/4] unionfs: remove cap_writeback_dirty test
Date: Tue, 18 Dec 2007 22:12:38 +0000 (GMT) [thread overview]
Message-ID: <Pine.LNX.4.64.0712182210440.28390@blonde.wat.veritas.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0712182207400.28390@blonde.wat.veritas.com>
Remove !mapping_cap_writeback_dirty shortcircuit from unionfs_writepages.
It was introduced to avoid the stray AOP_WRITEPAGE_ACTIVATE coming from
shmem_writepage; but that has since been fixed in shmem_writepage and in
write_cache_pages. It stayed because it looked like a good optimization,
not to waste time calling down to tmpfs when that would serve no purpose.
But in fact this optimization causes hangs when running LTP with unionfs
over tmpfs. The problem is that the test comes at the wrong level: unionfs
has already declared in its default_backing_dev_info that it's playing by
cap_writeback_dirty rules. If it does nothing here in its writepages, its
dirty pages accumulate and choke the system. What's needed is to carry on
down and let its pages be cleaned while in turn they dirty the lower level.
And this now has an additional benefit for tmpfs, that a sync or pdflush
pushes these pages down to shmem_writepage, letting it match the filepage
coming from unionfs with the swap which may have been allocated earlier,
so it can free the duplication sooner than waiting for further pressure.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
---
fs/unionfs/mmap.c | 3 ---
1 file changed, 3 deletions(-)
--- 2.6.24-rc5-mm1/fs/unionfs/mmap.c 2007-12-05 10:38:38.000000000 +0000
+++ unionfs1/fs/unionfs/mmap.c 2007-12-05 16:50:15.000000000 +0000
@@ -130,9 +130,6 @@ static int unionfs_writepages(struct add
if (!lower_inode)
goto out;
- if (!mapping_cap_writeback_dirty(lower_inode->i_mapping))
- goto out;
-
err = generic_writepages(mapping, wbc);
if (!err)
unionfs_copy_attr_times(inode);
next prev parent reply other threads:[~2007-12-18 22:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-18 22:10 [PATCH 0/4] unionfs: work better with tmpfs Hugh Dickins
2007-12-18 22:12 ` Hugh Dickins [this message]
2007-12-18 22:13 ` [PATCH 2/4] unionfs: 32-bit needs lock for i_size Hugh Dickins
2007-12-18 22:14 ` [PATCH 3/4] unionfs: restructure unionfs_setattr Hugh Dickins
2007-12-18 23:09 ` Erez Zadok
2007-12-19 0:53 ` Hugh Dickins
2007-12-19 1:14 ` Erez Zadok
2007-12-18 22:14 ` [PATCH 4/4] unionfs: fix truncation order Hugh Dickins
2007-12-28 21:09 ` [PATCH 0/4] unionfs: work better with tmpfs Erez Zadok
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.0712182210440.28390@blonde.wat.veritas.com \
--to=hugh@veritas.com \
--cc=akpm@linux-foundation.org \
--cc=ezk@cs.sunysb.edu \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®