From: Dave Chinner <david@fromorbit.com>
To: Michael Weissenbacher <mw@dermichi.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>, linux-xfs@vger.kernel.org
Subject: Re: xfsaild in D state seems to be blocking all other i/o sporadically
Date: Fri, 21 Apr 2017 09:16:03 +1000 [thread overview]
Message-ID: <20170420231603.GJ12369@dastard> (raw)
In-Reply-To: <f3e222a4-bcdb-6c61-79b0-1450c12e054f@dermichi.com>
On Thu, Apr 20, 2017 at 09:11:22AM +0200, Michael Weissenbacher wrote:
> On 20.04.2017 01:48, Dave Chinner wrote:
> > On Wed, Apr 19, 2017 at 11:47:43PM +0200, Michael Weissenbacher wrote:
> >> OK, do i understand you correctly that the xfsaild does all the actual
> >> work of updating the inodes? And it's doing that single-threaded,
> >> reading both the log and the indoes themselves?
> >
> > The problem is that the backing buffers that are used for flushing
> > inodes have been reclaimed due to memory pressure, but the inodes in
> > cache are still dirty. Hence to write the dirty inodes, we first
> > have to read the inode buffer back into memory.
> >
> Interesting find. Is there a way to prevent those buffers from getting
> reclaimed?
Not really. It's simply a side effect of memory reclaim not being
able to reclaim inodes or the page cache because they are dirty, and
so it goes and puts lots more pressure on clean caches. The working
set in those other caches gets trashed, and this it's a downward
spiral because it means dirty inodes and pages take longer are
require blocking IO to refill on demand...
> Would adjusting vfs_cache_pressure help?
Unlikely.
> Or adding more
> memory to the system?
Unlikely - that'll just lead to bigger stalls.
> In fact the best thing would be to disable file
> content caching completely. Because of the use-case (backup server) it's
> worthless to cache file content.
> My primary objective is to avoid those stalls and reduce latency, at the
> expense of throughput.
Set up dirty page cache writeback thresholds to be low (a couple of
hundred MB instead of 10/20% of memory) so that data writeback
starts early and throttles dirty pages to a small amount of memory.
This will help keep the page cache clean and immediately
reclaimable, hence it shouldn't put as much pressure on other caches
when memory reclaim is required.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2017-04-20 23:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-19 10:58 xfsaild in D state seems to be blocking all other i/o sporadically Michael Weissenbacher
2017-04-19 12:12 ` Carlos Maiolino
2017-04-19 12:37 ` Brian Foster
2017-04-19 12:40 ` Michael Weissenbacher
2017-04-19 13:01 ` Michael Weissenbacher
2017-04-19 14:04 ` Carlos Maiolino
2017-04-19 14:20 ` Carlos Maiolino
2017-04-19 16:40 ` Michael Weissenbacher
2017-04-19 16:36 ` Michael Weissenbacher
2017-04-19 18:08 ` Brian Foster
2017-04-19 20:10 ` Michael Weissenbacher
2017-04-19 20:55 ` Darrick J. Wong
2017-04-19 21:47 ` Michael Weissenbacher
2017-04-19 23:48 ` Dave Chinner
2017-04-20 7:11 ` Michael Weissenbacher
2017-04-20 23:16 ` Dave Chinner [this message]
2017-04-21 7:43 ` Michael Weissenbacher
2017-04-21 9:18 ` Shan Hai
2017-04-22 8:38 ` Michael Weissenbacher
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=20170420231603.GJ12369@dastard \
--to=david@fromorbit.com \
--cc=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=mw@dermichi.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