From: Johannes Weiner <jweiner@redhat.com>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Michal Hocko <mhocko@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>,
Christoph Hellwig <hch@infradead.org>,
Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.cz>,
Rik van Riel <riel@redhat.com>,
Minchan Kim <minchan.kim@gmail.com>,
Chris Mason <chris.mason@oracle.com>,
"Theodore Ts'o" <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
"Li, Shaohua" <shaohua.li@intel.com>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [patch 3/5] mm: try to distribute dirty pages fairly across zones
Date: Tue, 1 Nov 2011 11:52:57 +0100 [thread overview]
Message-ID: <20111101105257.GF5819@redhat.com> (raw)
In-Reply-To: <20111028203944.GB20607@localhost>
On Sat, Oct 29, 2011 at 04:39:44AM +0800, Wu Fengguang wrote:
> [restore CC list]
>
> > > I'm trying to understand where the performance gain comes from.
> > >
> > > I noticed that in all cases, before/after patchset, nr_vmscan_write are all zero.
> > >
> > > nr_vmscan_immediate_reclaim is significantly reduced though:
> >
> > That's a good thing, it means we burn less CPU time on skipping
> > through dirty pages on the LRU.
> >
> > Until a certain priority level, the dirty pages encountered on the LRU
> > list are marked PageReclaim and put back on the list, this is the
> > nr_vmscan_immediate_reclaim number. And only below that priority, we
> > actually ask the FS to write them, which is nr_vmscan_write.
>
> Yes, it is.
>
> > I suspect this is where the performance improvement comes from: we
> > find clean pages for reclaim much faster.
>
> That explains how it could reduce CPU overheads. However the dd's are
> throttled anyway, so I still don't understand how the speedup of dd page
> allocations improve the _IO_ performance.
They are throttled in balance_dirty_pages() when there are too many
dirty pages. But they are also 'throttled' in direct reclaim when
there are too many clean + dirty pages. Wild guess: speeding up
direct reclaim allows dirty pages to be generated faster and the
writer can better saturate the BDI?
Not all filesystems ignore all VM writepage requests, either. xfs
e.g. ignores only direct reclaim but honors requests from kswapd.
ext4 honors writepage whenever it pleases. On those, I can imagine
the reduced writepage intereference to help. But that can not be the
only reason as btrfs ignores writepage from the reclaim in general and
still sees improvement.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-11-01 10:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-30 7:17 [patch 0/5] per-zone dirty limits v3 Johannes Weiner
2011-09-30 7:17 ` [patch 1/5] mm: exclude reserved pages from dirtyable memory Johannes Weiner
2011-09-30 13:53 ` Michal Hocko
2011-10-01 7:10 ` Minchan Kim
2011-10-03 11:22 ` Mel Gorman
2011-09-30 7:17 ` [patch 2/5] mm: writeback: cleanups in preparation for per-zone dirty limits Johannes Weiner
2011-09-30 13:56 ` Michal Hocko
2011-09-30 7:17 ` [patch 3/5] mm: try to distribute dirty pages fairly across zones Johannes Weiner
2011-09-30 7:35 ` Pekka Enberg
2011-09-30 8:55 ` Johannes Weiner
2011-09-30 14:28 ` Michal Hocko
2011-10-28 20:18 ` Wu Fengguang
2011-10-31 11:33 ` Wu Fengguang
2011-11-01 10:55 ` Johannes Weiner
[not found] ` <20111027155618.GA25524@localhost>
[not found] ` <20111027161359.GA1319@redhat.com>
[not found] ` <20111027204743.GA19343@localhost>
[not found] ` <20111027221258.GA22869@localhost>
[not found] ` <20111027231933.GB1319@redhat.com>
2011-10-28 20:39 ` Wu Fengguang
2011-11-01 10:52 ` Johannes Weiner [this message]
2011-09-30 7:17 ` [patch 4/5] mm: filemap: pass __GFP_WRITE from grab_cache_page_write_begin() Johannes Weiner
2011-09-30 14:41 ` Michal Hocko
2011-09-30 7:17 ` [patch 5/5] Btrfs: pass __GFP_WRITE for buffered write page allocations Johannes Weiner
2011-10-03 11:25 ` Mel Gorman
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=20111101105257.GF5819@redhat.com \
--to=jweiner@redhat.com \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=chris.mason@oracle.com \
--cc=david@fromorbit.com \
--cc=fengguang.wu@intel.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=minchan.kim@gmail.com \
--cc=riel@redhat.com \
--cc=shaohua.li@intel.com \
--cc=tytso@mit.edu \
--cc=xfs@oss.sgi.com \
/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).