LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux-foundation.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: peterz@infradead.org, rientjes@google.com, npiggin@suse.de,
menage@google.com, dfults@sgi.com, linux-kernel@vger.kernel.org,
containers@lists.osdl.org
Subject: Re: [patch 0/7] cpuset writeback throttling
Date: Wed, 5 Nov 2008 14:21:47 -0600 (CST) [thread overview]
Message-ID: <Pine.LNX.4.64.0811051415360.31450@quilx.com> (raw)
In-Reply-To: <20081105104145.abd6fc91.akpm@linux-foundation.org>
On Wed, 5 Nov 2008, Andrew Morton wrote:
> > > Doable. lru->page->mapping->host is a good start.
> >
> > The block layer has a list of inodes that are dirty. From that we need to
> > select ones that will improve the situation from the cpuset/memcg. How
> > does the LRU come into this?
>
> In the simplest case, dirty-memory throttling can just walk the LRU
> writing back pages in the same way that kswapd does.
That means running reclaim. But we are only interested in getting rid of
dirty pages. Plus the filesystem guys have repeatedly pointed out that
page sized I/O to random places in a file is not a good thing to do. There
was actually talk of stopping kswapd from writing out pages!
> There would probably be performance benefits in doing
> address_space-ordered writeback, so the dirty-memory throttling could
> pick a dirty page off the LRU, go find its inode and then feed that
> into __sync_single_inode().
We cannot call into the writeback functions for an inode from a reclaim
context. We can write back single pages but not a range of pages from an
inode due to various locking issues (see discussion on slab defrag
patchset).
> > How do I get to the LRU from the dirtied list of inodes?
>
> Don't need it.
>
> It'll be approximate and has obvious scenarios of great inaccuraracy
> but it'll suffice for the workloads which this patchset addresses.
Sounds like a wild hack that runs against known limitations in terms
of locking etc.
> It sounds like any memcg-based approach just won't be suitable for the
> people who are hitting this problem.
Why not? If you can determine which memcgs an inode has dirty pages on
then the same scheme as proposed here will work.
> But _are_ people hitting this problem? I haven't seen any real-looking
> reports in ages. Is there some workaround? If so, what is it? How
> serious is this problem now?
Are there people who are actually having memcg based solutions deployed?
No enterprise release includes it yet so I guess that there is not much of
a use yet.
next prev parent reply other threads:[~2008-11-05 20:22 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-30 19:23 David Rientjes
2008-10-30 19:23 ` [patch 1/7] cpusets: add dirty map to struct address_space David Rientjes
2008-11-04 21:09 ` Andrew Morton
2008-11-04 21:20 ` Christoph Lameter
2008-11-04 21:42 ` Andrew Morton
2008-10-30 19:23 ` [patch 2/7] pdflush: allow the passing of a nodemask parameter David Rientjes
2008-10-30 19:23 ` [patch 3/7] mm: make page writeback obey cpuset constraints David Rientjes
2008-10-30 19:23 ` [patch 4/7] mm: cpuset aware reclaim writeout David Rientjes
2008-10-30 19:23 ` [patch 5/7] mm: throttle writeout with cpuset awareness David Rientjes
2008-10-30 19:23 ` [patch 6/7] cpusets: per cpuset dirty ratios David Rientjes
2008-10-30 19:23 ` [patch 7/7] cpusets: update documentation for writeback throttling David Rientjes
2008-10-30 21:08 ` [patch 0/7] cpuset " Dave Chinner
2008-10-30 21:33 ` Christoph Lameter
2008-10-30 22:03 ` Dave Chinner
2008-10-31 13:47 ` Christoph Lameter
2008-10-31 16:36 ` David Rientjes
2008-11-04 20:47 ` Andrew Morton
2008-11-04 20:53 ` Peter Zijlstra
2008-11-04 20:58 ` Christoph Lameter
2008-11-04 21:10 ` David Rientjes
2008-11-04 21:16 ` Andrew Morton
2008-11-04 21:21 ` Peter Zijlstra
2008-11-04 21:50 ` Andrew Morton
2008-11-04 22:17 ` Christoph Lameter
2008-11-04 22:35 ` Andrew Morton
2008-11-04 22:52 ` Christoph Lameter
2008-11-04 23:36 ` Andrew Morton
2008-11-05 1:31 ` KAMEZAWA Hiroyuki
2008-11-05 3:09 ` Andrew Morton
2008-11-05 2:45 ` Christoph Lameter
2008-11-05 3:05 ` Andrew Morton
2008-11-05 4:31 ` KAMEZAWA Hiroyuki
2008-11-10 9:02 ` Andrea Righi
2008-11-10 10:02 ` David Rientjes
2008-11-05 13:52 ` Christoph Lameter
2008-11-05 18:41 ` Andrew Morton
2008-11-05 20:21 ` Christoph Lameter [this message]
2008-11-05 20:31 ` Andrew Morton
2008-11-05 20:40 ` Christoph Lameter
2008-11-05 20:56 ` Andrew Morton
2008-11-05 21:28 ` Christoph Lameter
2008-11-05 21:55 ` Paul Menage
2008-11-05 22:04 ` David Rientjes
2008-11-06 1:34 ` KAMEZAWA Hiroyuki
2008-11-06 20:35 ` David Rientjes
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.0811051415360.31450@quilx.com \
--to=cl@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.osdl.org \
--cc=dfults@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=npiggin@suse.de \
--cc=peterz@infradead.org \
--cc=rientjes@google.com \
--subject='Re: [patch 0/7] cpuset writeback throttling' \
/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
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).