Subject: Re: [PATCHSET v3][RFC] Make background writeback not suck
To: Dave Chinner <david@fromorbit.com>
References: <1459350477-16404-1-git-send-email-axboe@fb.com>
 <pan$868e6$a5dea842$fc28bdb9$811a722b@googlemail.com>
 <20160401010134.GV11812@dastard>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
From: =?UTF-8?Q?Holger_Hoffst=c3=a4tte?= 
	<holger.hoffstaette@googlemail.com>
Organization: Applied Asynchrony, Inc.
Message-ID: <56FEA898.7070108@googlemail.com>
Date: Fri, 1 Apr 2016 18:58:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <20160401010134.GV11812@dastard>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 981
Lines: 28

On 04/01/16 03:01, Dave Chinner wrote:
> Can you go back to your original kernel, and lower nr_requests to 8?

Sure, did that and as expected it didn't help much. Under prolonged stress
it was actually even a bit worse than writeback throttling. IMHO that's not
really surprising either, since small queues now punish everyone and
in interactive mode I really want to e.g. start loading hundreds of small
thumbnails at once, or du a directory.

Instead of randomized aka manual/interactive testing I created a simple
stress tester:

#!/bin/sh
while [[ true ]]
do
    cp bigfile bigfile.out
done

and running that in the background turns the system into a tar pit,
which is laughable when you consider that I have 24G and 8 cores.

With the writeback patchset and wb_percent=1 (yes, really!) it is almost
unnoticeable, but according to nmon still writes ~250-280 MB/s.
This is with deadline on ext4 on an older SATA-3 SSD that can still
do peak ~465 MB/s (with dd).

cheers,
Holger