From: Wu Fengguang <fengguang.wu@intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Richard Kennedy <richard@rsk.demon.co.uk>,
Dave Chinner <david@fromorbit.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/6] writeback: reduce calls to global_page_state in balance_dirty_pages()
Date: Tue, 27 Jul 2010 11:59:41 +0800 [thread overview]
Message-ID: <20100727035941.GA15007@localhost> (raw)
In-Reply-To: <20100726151946.GH3280@quack.suse.cz>
> > This patch slightly changes behavior by replacing clip_bdi_dirty_limit()
> > with the explicit check (nr_reclaimable + nr_writeback >= dirty_thresh)
> > to avoid exceeding the dirty limit. Since the bdi dirty limit is mostly
> > accurate we don't need to do routinely clip. A simple dirty limit check
> > would be enough.
> >
> > The check is necessary because, in principle we should throttle
> > everything calling balance_dirty_pages() when we're over the total
> > limit, as said by Peter.
> >
> > We now set and clear dirty_exceeded not only based on bdi dirty limits,
> > but also on the global dirty limits. This is a bit counterintuitive, but
> > the global limits are the ultimate goal and shall be always imposed.
> Thinking about this again - what you did is rather big change for systems
> with more active BDIs. For example if I have two disks sda and sdb and
> write for some time to sda, then dirty limit for sdb gets scaled down.
> So when we start writing to sbd we'll heavily throttle the threads until
> the dirty limit for sdb ramps up regardless of how far are we to reach the
> global limit...
The global threshold check is added in place of clip_bdi_dirty_limit()
for safety and not intended as a behavior change. If ever leading to
big behavior change and regression, that it would be indicating some
too permissive per-bdi threshold calculation.
Did you see the global dirty threshold get exceeded when writing to 2+
devices? Occasional small exceeding should be OK though. I tried the
following debug patch and see no warnings when doing two concurrent cp
over local disk and NFS.
Index: linux-next/mm/page-writeback.c
===================================================================
--- linux-next.orig/mm/page-writeback.c 2010-07-27 11:26:18.063817669 +0800
+++ linux-next/mm/page-writeback.c 2010-07-27 11:26:53.335855847 +0800
@@ -513,6 +513,11 @@
if (!dirty_exceeded)
break;
+ if (nr_reclaimable + nr_writeback >= dirty_thresh)
+ printk ("XXX: dirty exceeded: %lu + %lu = %lu ++ %lu\n",
+ nr_reclaimable, nr_writeback, dirty_thresh,
+ nr_reclaimable + nr_writeback - dirty_thresh);
+
/*
* Throttle it only when the background writeback cannot
* catch-up. This avoids (excessively) small writeouts
Thanks,
Fengguang
WARNING: multiple messages have this Message-ID (diff)
From: Wu Fengguang <fengguang.wu@intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Richard Kennedy <richard@rsk.demon.co.uk>,
Dave Chinner <david@fromorbit.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/6] writeback: reduce calls to global_page_state in balance_dirty_pages()
Date: Tue, 27 Jul 2010 11:59:41 +0800 [thread overview]
Message-ID: <20100727035941.GA15007@localhost> (raw)
In-Reply-To: <20100726151946.GH3280@quack.suse.cz>
> > This patch slightly changes behavior by replacing clip_bdi_dirty_limit()
> > with the explicit check (nr_reclaimable + nr_writeback >= dirty_thresh)
> > to avoid exceeding the dirty limit. Since the bdi dirty limit is mostly
> > accurate we don't need to do routinely clip. A simple dirty limit check
> > would be enough.
> >
> > The check is necessary because, in principle we should throttle
> > everything calling balance_dirty_pages() when we're over the total
> > limit, as said by Peter.
> >
> > We now set and clear dirty_exceeded not only based on bdi dirty limits,
> > but also on the global dirty limits. This is a bit counterintuitive, but
> > the global limits are the ultimate goal and shall be always imposed.
> Thinking about this again - what you did is rather big change for systems
> with more active BDIs. For example if I have two disks sda and sdb and
> write for some time to sda, then dirty limit for sdb gets scaled down.
> So when we start writing to sbd we'll heavily throttle the threads until
> the dirty limit for sdb ramps up regardless of how far are we to reach the
> global limit...
The global threshold check is added in place of clip_bdi_dirty_limit()
for safety and not intended as a behavior change. If ever leading to
big behavior change and regression, that it would be indicating some
too permissive per-bdi threshold calculation.
Did you see the global dirty threshold get exceeded when writing to 2+
devices? Occasional small exceeding should be OK though. I tried the
following debug patch and see no warnings when doing two concurrent cp
over local disk and NFS.
Index: linux-next/mm/page-writeback.c
===================================================================
--- linux-next.orig/mm/page-writeback.c 2010-07-27 11:26:18.063817669 +0800
+++ linux-next/mm/page-writeback.c 2010-07-27 11:26:53.335855847 +0800
@@ -513,6 +513,11 @@
if (!dirty_exceeded)
break;
+ if (nr_reclaimable + nr_writeback >= dirty_thresh)
+ printk ("XXX: dirty exceeded: %lu + %lu = %lu ++ %lu\n",
+ nr_reclaimable, nr_writeback, dirty_thresh,
+ nr_reclaimable + nr_writeback - dirty_thresh);
+
/*
* Throttle it only when the background writeback cannot
* catch-up. This avoids (excessively) small writeouts
Thanks,
Fengguang
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-07-27 4:00 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-11 2:06 [PATCH 0/6] writeback cleanups and trivial fixes Wu Fengguang
2010-07-11 2:06 ` Wu Fengguang
2010-07-11 2:06 ` Wu Fengguang
2010-07-11 2:06 ` [PATCH 1/6] writeback: take account of NR_WRITEBACK_TEMP in balance_dirty_pages() Wu Fengguang
2010-07-11 2:06 ` Wu Fengguang
2010-07-12 21:52 ` Andrew Morton
2010-07-12 21:52 ` Andrew Morton
2010-07-12 21:52 ` Andrew Morton
2010-07-13 8:58 ` Miklos Szeredi
2010-07-13 8:58 ` Miklos Szeredi
2010-07-15 14:50 ` Wu Fengguang
2010-07-15 14:50 ` Wu Fengguang
2010-07-11 2:06 ` [PATCH 2/6] writeback: reduce calls to global_page_state " Wu Fengguang
2010-07-11 2:06 ` Wu Fengguang
2010-07-11 2:06 ` Wu Fengguang
2010-07-26 15:19 ` Jan Kara
2010-07-26 15:19 ` Jan Kara
2010-07-27 3:59 ` Wu Fengguang [this message]
2010-07-27 3:59 ` Wu Fengguang
2010-07-27 9:12 ` Jan Kara
2010-07-27 9:12 ` Jan Kara
2010-07-28 2:04 ` Wu Fengguang
2010-07-28 2:04 ` Wu Fengguang
2010-08-03 14:55 ` Peter Zijlstra
2010-08-03 14:55 ` Peter Zijlstra
2010-07-11 2:06 ` [PATCH 3/6] writeback: avoid unnecessary calculation of bdi dirty thresholds Wu Fengguang
2010-07-11 2:06 ` Wu Fengguang
2010-07-11 2:06 ` Wu Fengguang
2010-07-12 21:56 ` Andrew Morton
2010-07-12 21:56 ` Andrew Morton
2010-07-12 21:56 ` Andrew Morton
2010-07-15 14:55 ` Wu Fengguang
2010-07-15 14:55 ` Wu Fengguang
2010-07-19 21:35 ` Andrew Morton
2010-07-19 21:35 ` Andrew Morton
2010-07-19 21:35 ` Andrew Morton
2010-07-20 3:34 ` Wu Fengguang
2010-07-20 3:34 ` Wu Fengguang
2010-07-20 3:34 ` Wu Fengguang
2010-07-20 4:14 ` Andrew Morton
2010-07-20 4:14 ` Andrew Morton
2010-08-03 15:03 ` Peter Zijlstra
2010-08-03 15:03 ` Peter Zijlstra
2010-08-03 15:10 ` Wu Fengguang
2010-08-03 15:10 ` Wu Fengguang
2010-08-04 16:41 ` Wu Fengguang
2010-08-04 16:41 ` Wu Fengguang
2010-08-04 17:10 ` Peter Zijlstra
2010-08-04 17:10 ` Peter Zijlstra
2010-07-11 2:07 ` [PATCH 4/6] writeback: dont redirty tail an inode with dirty pages Wu Fengguang
2010-07-11 2:07 ` Wu Fengguang
2010-07-12 2:01 ` Dave Chinner
2010-07-12 2:01 ` Dave Chinner
2010-07-12 15:31 ` Wu Fengguang
2010-07-12 15:31 ` Wu Fengguang
2010-07-12 22:13 ` Andrew Morton
2010-07-12 22:13 ` Andrew Morton
2010-07-15 15:35 ` Wu Fengguang
2010-07-15 15:35 ` Wu Fengguang
2010-07-11 2:07 ` [PATCH 5/6] writeback: fix queue_io() ordering Wu Fengguang
2010-07-11 2:07 ` Wu Fengguang
2010-07-11 2:07 ` Wu Fengguang
2010-07-12 22:15 ` Andrew Morton
2010-07-12 22:15 ` Andrew Morton
2010-07-12 22:15 ` Andrew Morton
2010-07-11 2:07 ` [PATCH 6/6] writeback: merge for_kupdate and !for_kupdate cases Wu Fengguang
2010-07-11 2:07 ` Wu Fengguang
2010-07-12 2:08 ` Dave Chinner
2010-07-12 2:08 ` Dave Chinner
2010-07-12 15:52 ` Wu Fengguang
2010-07-12 15:52 ` Wu Fengguang
2010-07-12 22:06 ` Dave Chinner
2010-07-12 22:06 ` Dave Chinner
2010-07-12 22:22 ` Andrew Morton
2010-07-12 22:22 ` Andrew Morton
2010-08-05 16:01 ` Wu Fengguang
2010-08-05 16:01 ` Wu Fengguang
2010-07-11 2:44 ` [PATCH 0/6] writeback cleanups and trivial fixes Christoph Hellwig
2010-07-11 2:44 ` Christoph Hellwig
2010-07-11 2:50 ` Wu Fengguang
2010-07-11 2:50 ` Wu Fengguang
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=20100727035941.GA15007@localhost \
--to=fengguang.wu@intel.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=richard@rsk.demon.co.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.