[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <787373.9318.qm@web113309.mail.gq1.yahoo.com>
Date: Tue, 22 Dec 2009 05:01:46 -0800 (PST)
From: Martin Knoblauch <knobi@...bisoft.de>
To: Wu Fengguang <fengguang.wu@...el.com>,
Steve Rago <sar@...-labs.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Trond.Myklebust@...app.com" <Trond.Myklebust@...app.com>,
"jens.axboe" <jens.axboe@...cle.com>
Subject: Re: [PATCH] improve the performance of large sequential write NFS workloads
----- Original Message ----
> From: Wu Fengguang <fengguang.wu@...el.com>
> To: Steve Rago <sar@...-labs.com>
> Cc: Peter Zijlstra <peterz@...radead.org>; "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>; "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>; "Trond.Myklebust@...app.com" <Trond.Myklebust@...app.com>; jens.axboe <jens.axboe@...cle.com>
> Sent: Tue, December 22, 2009 2:59:07 AM
> Subject: Re: [PATCH] improve the performance of large sequential write NFS workloads
>
[big snip]
>
> In general it's reasonable to keep NFS per-file nr_dirty low, however
> questionable to do per-file nr_writeback throttling. This does not
> work well with the global limits - eg. when there are many dirty
> files, the summed-up nr_writeback will still grow out of control.
> And it's more likely to impact user visible responsiveness than
> a global limit. But my opinion can be biased -- me have a patch to
> do global NFS nr_writeback limit ;)
>
is that "NFS: introduce writeback wait queue", which you sent me a while ago and I did not test until now :-( ?
Cheers
Martin
--
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