From: NeilBrown <neilb@suse.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Jan Kara <jack@suse.cz>, Jeff Layton <jlayton@redhat.com>,
Trond Myklebust <trond.myklebust@primarydata.com>,
Dave Chinner <david@fromorbit.com>,
"J. Bruce Fields" <bfields@fieldses.org>,
Mel Gorman <mgorman@suse.com>,
linux-mm@kvack.org, linux-nfs@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] MM: avoid throttling reclaim for loop-back nfsd threads.
Date: Thu, 24 Apr 2014 08:47:40 +1000 [thread overview]
Message-ID: <20140424084740.44a416e4@notabene.brown> (raw)
In-Reply-To: <20140423150318.d4bcf234faa5bea7fcb57b9b@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 3508 bytes --]
On Wed, 23 Apr 2014 15:03:18 -0700 Andrew Morton <akpm@linux-foundation.org>
wrote:
> On Wed, 23 Apr 2014 12:40:58 +1000 NeilBrown <neilb@suse.de> wrote:
>
> > When a loop-back NFS mount is active and the backing device for the
> > NFS mount becomes congested, that can impose throttling delays on the
> > nfsd threads.
> >
> > These delays significantly reduce throughput and so the NFS mount
> > remains congested.
> >
> > This results in a live lock and the reduced throughput persists.
> >
> > This live lock has been found in testing with the 'wait_iff_congested'
> > call, and could possibly be caused by the 'congestion_wait' call.
> >
> > This livelock is similar to the deadlock which justified the
> > introduction of PF_LESS_THROTTLE, and the same flag can be used to
> > remove this livelock.
> >
> > To minimise the impact of the change, we still throttle nfsd when the
> > filesystem it is writing to is congested, but not when some separate
> > filesystem (e.g. the NFS filesystem) is congested.
> >
> > Signed-off-by: NeilBrown <neilb@suse.de>
> > ---
> > mm/vmscan.c | 18 ++++++++++++++++--
> > 1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index a9c74b409681..e011a646de95 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -1424,6 +1424,18 @@ putback_inactive_pages(struct lruvec *lruvec, struct list_head *page_list)
> > list_splice(&pages_to_free, page_list);
> > }
> >
> > +/* If a kernel thread (such as nfsd for loop-back mounts) services
>
> /*
> * If ...
>
> please
>
> > + * a backing device by writing to the page cache it sets PF_LESS_THROTTLE.
> > + * In that case we should only throttle if the backing device it is
> > + * writing to is congested. In other cases it is safe to throttle.
> > + */
> > +static int current_may_throttle(void)
> > +{
> > + return !(current->flags & PF_LESS_THROTTLE) ||
> > + current->backing_dev_info == NULL ||
> > + bdi_write_congested(current->backing_dev_info);
> > +}
> > +
> > /*
> > * shrink_inactive_list() is a helper for shrink_zone(). It returns the number
> > * of reclaimed pages
> > @@ -1552,7 +1564,8 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec,
> > * implies that pages are cycling through the LRU faster than
> > * they are written so also forcibly stall.
> > */
> > - if (nr_unqueued_dirty == nr_taken || nr_immediate)
> > + if ((nr_unqueued_dirty == nr_taken || nr_immediate)
> > + && current_may_throttle())
>
> foo &&
> bar
>
> please. As you did in in current_may_throttle().
>
> > congestion_wait(BLK_RW_ASYNC, HZ/10);
> > }
> >
> > @@ -1561,7 +1574,8 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec,
> > * is congested. Allow kswapd to continue until it starts encountering
> > * unqueued dirty pages or cycling through the LRU too quickly.
> > */
> > - if (!sc->hibernation_mode && !current_is_kswapd())
> > + if (!sc->hibernation_mode && !current_is_kswapd()
> > + && current_may_throttle())
>
> ditto
>
> > wait_iff_congested(zone, BLK_RW_ASYNC, HZ/10);
> >
> > trace_mm_vmscan_lru_shrink_inactive(zone->zone_pgdat->node_id,
> >
Thanks. I've made those changes and will resend just that patch.
As it is quite independent of all the others can you take it and I'll funnel
the others through other trees?
Thanks
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2014-04-23 22:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-23 2:40 [PATCH/RFC 0/5] Support loop-back NFS mounts - take 2 NeilBrown
2014-04-23 2:40 ` [PATCH 5/5] NFS: avoid deadlocks with loop-back mounted NFS filesystems NeilBrown
2014-04-23 2:40 ` [PATCH 4/5] SUNRPC: track when a client connection is routed to the local host NeilBrown
2014-04-23 13:44 ` Anna Schumaker
2014-04-23 23:14 ` NeilBrown
2014-04-24 12:46 ` Anna Schumaker
2014-04-23 2:40 ` [PATCH 3/5] nfsd: Only set PF_LESS_THROTTLE when really needed NeilBrown
2014-05-06 20:54 ` J. Bruce Fields
2014-05-12 1:05 ` NeilBrown
2014-05-06 21:05 ` Rik van Riel
2014-05-12 1:04 ` NeilBrown
2014-05-12 15:32 ` Jan Kara
2014-04-23 2:40 ` [PATCH 2/5] SUNRPC: track whether a request is coming from a loop-back interface NeilBrown
2014-04-23 2:40 ` [PATCH 1/5] MM: avoid throttling reclaim for loop-back nfsd threads NeilBrown
2014-04-23 22:03 ` Andrew Morton
2014-04-23 22:47 ` NeilBrown [this message]
2014-04-24 1:20 ` [PATCH/RFC 0/5] Support loop-back NFS mounts - take 2 Dave Chinner
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=20140424084740.44a416e4@notabene.brown \
--to=neilb@suse.de \
--cc=akpm@linux-foundation.org \
--cc=bfields@fieldses.org \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=jlayton@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=mgorman@suse.com \
--cc=trond.myklebust@primarydata.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).