[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1262807594.4251.155.camel@localhost>
Date: Wed, 06 Jan 2010 14:53:14 -0500
From: Trond Myklebust <Trond.Myklebust@...app.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Wu Fengguang <fengguang.wu@...el.com>, Jan Kara <jack@...e.cz>,
Steve Rago <sar@...-labs.com>,
"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"jens.axboe" <jens.axboe@...cle.com>,
Peter Staubach <staubach@...hat.com>,
Arjan van de Ven <arjan@...radead.org>,
Ingo Molnar <mingo@...e.hu>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] improve the performance of large sequential write NFS
workloads
On Wed, 2010-01-06 at 14:21 -0500, Trond Myklebust wrote:
> On Wed, 2010-01-06 at 20:07 +0100, Peter Zijlstra wrote:
> > On Wed, 2010-01-06 at 13:52 -0500, Trond Myklebust wrote:
> > > On Wed, 2010-01-06 at 19:37 +0100, Peter Zijlstra wrote:
> > > > On Wed, 2010-01-06 at 13:26 -0500, Trond Myklebust wrote:
> > > > > OK. It looks as if the only key to finding out how many unstable writes
> > > > > we have is to use global_page_state(NR_UNSTABLE_NFS), so we can't
> > > > > specifically target our own backing-dev.
> > > >
> > > > Would be a simple matter of splitting BDI_UNSTABLE out from
> > > > BDI_RECLAIMABLE, no?
> > > >
> > > > Something like
> > >
> > > OK. How about if we also add in a bdi->capabilities flag to tell that we
> > > might have BDI_UNSTABLE? That would allow us to avoid the potentially
> > > expensive extra calls to bdi_stat() and bdi_stat_sum() for the non-nfs
> > > case?
> >
> > The bdi_stat_sum() in the error limit is basically the only such
> > expensive op, but I suspect we might hit that more than enough. So sure
> > that sounds like a plan.
> >
>
> This should apply on top of your patch....
...and finally, this should convert the previous NFS patch to use the
per-bdi accounting.
Cheers
Trond
--------------------------------------------------------------------------------------
VM: Use per-bdi unstable accounting to improve use of wbc->force_commit
From: Trond Myklebust <Trond.Myklebust@...app.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@...app.com>
---
mm/page-writeback.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index d90a0db..c537543 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -487,7 +487,6 @@ static void balance_dirty_pages(struct address_space *mapping,
{
long nr_reclaimable, bdi_nr_reclaimable;
long nr_writeback, bdi_nr_writeback;
- long nr_unstable_nfs;
unsigned long background_thresh;
unsigned long dirty_thresh;
unsigned long bdi_thresh;
@@ -504,18 +503,20 @@ static void balance_dirty_pages(struct address_space *mapping,
.nr_to_write = write_chunk,
.range_cyclic = 1,
};
+ long bdi_nr_unstable = 0;
get_dirty_limits(&background_thresh, &dirty_thresh,
&bdi_thresh, bdi);
- nr_unstable_nfs = global_page_state(NR_UNSTABLE_NFS);
nr_reclaimable = global_page_state(NR_FILE_DIRTY) +
- nr_unstable_nfs;
+ global_page_state(NR_UNSTABLE_NFS);
nr_writeback = global_page_state(NR_WRITEBACK);
bdi_nr_reclaimable = bdi_stat(bdi, BDI_DIRTY);
- if (bdi_cap_account_unstable(bdi))
- bdi_nr_reclaimable += bdi_stat(bdi, BDI_UNSTABLE);
+ if (bdi_cap_account_unstable(bdi)) {
+ bdi_nr_unstable = bdi_stat(bdi, BDI_UNSTABLE);
+ bdi_nr_reclaimable += bdi_nr_unstable;
+ }
bdi_nr_writeback = bdi_stat(bdi, BDI_WRITEBACK);
if (bdi_nr_reclaimable + bdi_nr_writeback <= bdi_thresh)
@@ -545,7 +546,7 @@ static void balance_dirty_pages(struct address_space *mapping,
if (bdi_nr_reclaimable > bdi_thresh) {
wbc.force_commit = 0;
/* Force NFS to also free up unstable writes. */
- if (nr_unstable_nfs > nr_reclaimable / 2)
+ if (bdi_nr_unstable > bdi_nr_reclaimable / 2)
wbc.force_commit = 1;
writeback_inodes_wbc(&wbc);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists