linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@fb.com>
To: <linux-kernel@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
	<linux-block@vger.kernel.org>
Subject: Re: [PATCHSET v2][RFC] Make background writeback not suck
Date: Thu, 24 Mar 2016 11:42:19 -0600	[thread overview]
Message-ID: <56F426FB.2010002@fb.com> (raw)
In-Reply-To: <56F2B8B5.10106@fb.com>

On 03/23/2016 09:39 AM, Jens Axboe wrote:
> Hi,
>
> Apparently I dropped the subject on this one, it's of course v2 of the
> writeback not sucking patchset...

Some test result. I've run a lot of them, on various types of storage, 
and performance seems good with the default settings.

This case reads in a file and writes it to stdout. It targets a certain 
latency for the reads - by default it's 10ms. If a read isn't done my 
10ms, it'll queue the next read. This avoids the coordinated omission 
problem, where one long latency is in fact many of them, you just don't 
knows since you don't issue more while one is stuck.

The test case reads a compressed file, and writes it over a pipe to gzip 
to decompress it. The input file is around 9G, uncompresses to 20G. At 
the end of the run, latency results are shown. Every time the target 
latency is exceeded during the run, it's output.

To keep the system busy, 75% (24G) of the memory is taking up by CPU 
hogs. This is intended to make the case worse for the throttled depth, 
as Dave pointed out.

Out-of-the-box results:

# time (./read-to-pipe-async -f randfile.gz | gzip -dc > outfile; sync)
read latency=11790 usec
read latency=82697 usec
[...]
Latency percentiles (usec) (READERS)
	50.0000th: 4
	75.0000th: 5
	90.0000th: 6
	95.0000th: 7
	99.0000th: 54
	99.5000th: 64
	99.9000th: 334
	99.9900th: 17952
	99.9990th: 101504
	99.9999th: 203520
	Over=333, min=0, max=215367
Latency percentiles (usec) (WRITERS)
	50.0000th: 3
	75.0000th: 5
	90.0000th: 454
	95.0000th: 473
	99.0000th: 615
	99.5000th: 625
	99.9000th: 815
	99.9900th: 1142
	99.9990th: 2244
	99.9999th: 10032
	Over=3, min=0, max=10811
Read rate (KB/sec) : 88988
Write rate (KB/sec): 60019

real	2m38.701s
user	2m33.030s
sys	1m31.540s

215ms worst case latency, 333 cases of being above the 10ms target. And 
with the patchset applied:

# time (./read-to-pipe-async -f randfile.gz | gzip -dc > outfile; sync)
write latency=15394 usec
[...]
Latency percentiles (usec) (READERS)
	50.0000th: 4
	75.0000th: 5
	90.0000th: 6
	95.0000th: 8
	99.0000th: 55
	99.5000th: 64
	99.9000th: 338
	99.9900th: 2652
	99.9990th: 3964
	99.9999th: 7464
	Over=1, min=0, max=10221
Latency percentiles (usec) (WRITERS)
	50.0000th: 4
	75.0000th: 5
	90.0000th: 450
	95.0000th: 471
	99.0000th: 611
	99.5000th: 623
	99.9000th: 703
	99.9900th: 1106
	99.9990th: 2010
	99.9999th: 10448
	Over=6, min=1, max=15394
Read rate (KB/sec) : 95506
Write rate (KB/sec): 59970

real	2m39.014s
user	2m33.800s
sys	1m35.210s

I won't bore you with vmstat output, it's pretty messy for the default case.

-- 
Jens Axboe


      reply	other threads:[~2016-03-24 17:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-23 15:25 Jens Axboe
2016-03-23 15:25 ` [PATCH 1/8] writeback: propagate the various reasons for writeback Jens Axboe
2016-03-23 15:25 ` [PATCH 2/8] writeback: add wbc_to_write() Jens Axboe
2016-03-23 15:25 ` [PATCH 3/8] writeback: use WRITE_SYNC for reclaim or sync writeback Jens Axboe
2016-03-23 15:25 ` [PATCH 4/8] writeback: track if we're sleeping on progress in balance_dirty_pages() Jens Axboe
2016-03-23 15:25 ` [PATCH 5/8] block: add ability to flag write back caching on a device Jens Axboe
2016-03-23 15:25 ` [PATCH 6/8] sd: inform block layer of write cache state Jens Axboe
2016-03-23 15:25 ` [PATCH 7/8] NVMe: " Jens Axboe
2016-03-23 15:25 ` [PATCH 8/8] writeback: throttle buffered writeback Jens Axboe
2016-03-23 15:39 ` [PATCHSET v2][RFC] Make background writeback not suck Jens Axboe
2016-03-24 17:42   ` Jens Axboe [this message]

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=56F426FB.2010002@fb.com \
    --to=axboe@fb.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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).