From: Peter Zijlstra <peterz@infradead.org>
To: Steve Rago <sar@nec-labs.com>
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
Trond.Myklebust@netapp.com, Wu Fengguang <fengguang.wu@intel.com>,
"jens.axboe" <jens.axboe@oracle.com>
Subject: Re: [PATCH] improve the performance of large sequential write NFS workloads
Date: Fri, 18 Dec 2009 20:44:03 +0100 [thread overview]
Message-ID: <1261165443.20899.555.camel@laptop> (raw)
In-Reply-To: <1261164799.1947.123.camel@serenity>
On Fri, 2009-12-18 at 14:33 -0500, Steve Rago wrote:
> > > +void nfs_wait_woutstanding(struct inode *inode)
> > > +{
> > > + if (nfs_max_woutstanding != 0) {
> > > + unsigned long background_thresh;
> > > + unsigned long dirty_thresh;
> > > + long npages;
> > > + struct nfs_inode *nfsi = NFS_I(inode);
> > > +
> > > + get_dirty_limits(&background_thresh, &dirty_thresh, NULL, NULL);
> > > + npages = global_page_state(NR_FILE_DIRTY) +
> > > + global_page_state(NR_UNSTABLE_NFS) +
> > > + global_page_state(NR_WRITEBACK);
> > > + if (npages >= background_thresh)
> > > + wait_event(nfsi->writes_wq,
> > > + atomic_read(&nfsi->writes) < nfs_max_woutstanding);
> > > + }
> > > +}
> >
> > This looks utterly busted too, why the global state and not the nfs
> > client's bdi state?
> >
> > Also, why create this extra workqueue and not simply use the congestion
> > interface that is present? If the congestion stuff doesn't work for you,
> > fix that, don't add extra muck like this.
>
> Pages are a global resource. Once we hit the dirty_threshold, the
> system is going to work harder to flush the pages out. This code
> prevents the caller from creating more dirty pages in this state,
> thereby making matters worse, when eager writeback is enabled.
You misunderstand, dirty limits are per BDI, all those npages might be
for !NFS traffic, in which case forcing the NFS into sync mode might be
the wrong thing to do.
The dirty pages are no longer a global resource in the current Linux
tree.
> This wait queue is used for different purposes than the congestion_wait
> interface. Here we are preventing the caller from proceeding if there
> are too many NFS writes outstanding for this thread and we are in a
> memory pressure state. It has nothing to do with the state of the bdi
> congestion.
I'm thinking it ought to, congestion is exactly that, when the device
gets backed up and need to get moving.
next prev parent reply other threads:[~2009-12-18 19:44 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-17 2:03 [PATCH] improve the performance of large sequential write NFS workloads Steve Rago
2009-12-17 8:17 ` Peter Zijlstra
2009-12-18 19:33 ` Steve Rago
2009-12-18 19:41 ` Ingo Molnar
2009-12-18 21:20 ` Steve Rago
2009-12-18 22:07 ` Ingo Molnar
2009-12-18 22:46 ` Steve Rago
2009-12-19 8:08 ` Arjan van de Ven
2009-12-19 13:37 ` Steve Rago
2009-12-18 19:44 ` Peter Zijlstra [this message]
2009-12-19 12:20 ` Wu Fengguang
2009-12-19 14:25 ` Steve Rago
2009-12-22 1:59 ` Wu Fengguang
2009-12-22 12:35 ` Jan Kara
2009-12-23 8:43 ` Christoph Hellwig
2009-12-23 13:32 ` Jan Kara
2009-12-24 5:25 ` Wu Fengguang
2009-12-24 1:26 ` Wu Fengguang
2009-12-22 13:01 ` Martin Knoblauch
2009-12-24 1:46 ` Wu Fengguang
2009-12-22 16:41 ` Steve Rago
2009-12-24 1:21 ` Wu Fengguang
2009-12-24 14:49 ` Steve Rago
2009-12-25 7:37 ` Wu Fengguang
2009-12-23 14:21 ` Trond Myklebust
2009-12-23 18:05 ` Jan Kara
2009-12-23 19:12 ` Trond Myklebust
2009-12-24 2:52 ` Wu Fengguang
2009-12-24 12:04 ` Trond Myklebust
2009-12-25 5:56 ` Wu Fengguang
2009-12-30 16:22 ` Trond Myklebust
2009-12-31 5:04 ` Wu Fengguang
2009-12-31 19:13 ` Trond Myklebust
2010-01-06 3:03 ` Wu Fengguang
2010-01-06 16:56 ` Trond Myklebust
2010-01-06 18:26 ` Trond Myklebust
2010-01-06 18:37 ` Peter Zijlstra
2010-01-06 18:52 ` Trond Myklebust
2010-01-06 19:07 ` Peter Zijlstra
2010-01-06 19:21 ` Trond Myklebust
2010-01-06 19:53 ` Trond Myklebust
2010-01-06 20:09 ` Jan Kara
2009-12-22 12:25 ` Jan Kara
2009-12-22 12:38 ` Peter Zijlstra
2009-12-22 12:55 ` Jan Kara
2009-12-22 16:20 ` Steve Rago
2009-12-23 18:39 ` Jan Kara
2009-12-23 20:16 ` Steve Rago
2009-12-23 21:49 ` Trond Myklebust
2009-12-23 23:13 ` Steve Rago
2009-12-23 23:44 ` Trond Myklebust
2009-12-24 4:30 ` Steve Rago
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=1261165443.20899.555.camel@laptop \
--to=peterz@infradead.org \
--cc=Trond.Myklebust@netapp.com \
--cc=fengguang.wu@intel.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=sar@nec-labs.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