linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: Linux Memory Management List <linux-mm@kvack.org>,
	linux-fsdevel@vger.kernel.org
Subject: [rfc] approach to pull writepage out of reclaim
Date: Thu, 9 Oct 2008 16:41:03 +0200	[thread overview]
Message-ID: <20081009144103.GE9941@wotan.suse.de> (raw)

Hi,

Just got bored of looking at other things, and started coding up the first
step to remove writepage from vmscan.

Actually, I lied slightly at kernel summit when I said we should be able to do
this easily and that it doesn't matter if filesystems today return immediately.
Higher order targetted page reclaim really does want to clean *this page*.
Fortunately it is going to be most important for swap (anonymous pages) because
file pages have much lower dirty thresholds.

However, we probably do want filesystems to be able to support this more
easily. The lock_page problem is a hard one *if* we assume writepage off the
LRU is an important fastpath. However, if we only ever run it for higher
order reclaim, then we're in a better position to handle it. The problem is
that we don't have a reference on the inode, so we can't dereference
page->mapping. The solution we can do is to lock the page, take a ref to
the inode, unlock the page, then call writepage (which would then lock the
page etc). So: slower, but with some effort it becomes a slowpath anyway.

So. Firstly, what I'm looking at is doing swap writeout from pdflush. This
patch does that (working in concept, but pdflush and background writeout
from dirty inode list isn't really up to the task, might scrap it and do the
writeout from kswap). But writeout from radix-tree should actually be able to
give better swapout pattern than LRU writepage as well.

My plan is to get this idea working, so writepage from pageout becomes a
slowpath.

Then fix the inode reference problem in vmscan.

Then change the calling convention of writepage to accept an unlocked page (at
the same time, don't clean the page before calling it. that's so stupid it
upsets me, and it really actually isn't much filesystem churn to fix).

Then perhaps look at removing direct calls to ->writepage() except in wrappers
such as generic_writepages, because at this point ->writepages should be
able to substitute. This is a relatively small step; more important are the
previous things.



             reply	other threads:[~2008-10-09 14:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-09 14:41 Nick Piggin [this message]
2008-10-09 17:06 ` [rfc] approach to pull writepage out of reclaim Christoph Lameter
2008-10-09 19:44   ` Matthew Wilcox
2008-10-09 20:45     ` Christoph Lameter
2008-10-10  2:44       ` Nick Piggin
2008-10-10  7:21 ` KAMEZAWA Hiroyuki
2008-10-11  4:13   ` Nick Piggin

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=20081009144103.GE9941@wotan.suse.de \
    --to=npiggin@suse.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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).