linux-kernel - Re: [PATCH 6/6] writeback: throttle buffered writeback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <x49poumb6mm.fsf@segfault.boston.devel.redhat.com>
Date:	Tue, 22 Mar 2016 16:27:29 -0400
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Jens Axboe <axboe@...com>
Cc:	<linux-kernel@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
	<linux-block@...r.kernel.org>
Subject: Re: [PATCH 6/6] writeback: throttle buffered writeback

Jens Axboe <axboe@...com> writes:

> On 03/22/2016 02:12 PM, Jeff Moyer wrote:
>> Hi, Jens,
>>
>> Jens Axboe <axboe@...com> writes:
>>
>>> If the device has write back caching, 'wb_cache_delay' delays by
>>> this amount of usecs when a write completes before allowing more.
>>
>> What's the reason behind that?
>
> For classic write back caching, the cache can absorb a bunch of writes
> shortly, which means that the completion cost only shows a small part
> of the overall cost. This means that if we just throttle on
> completion, then when the device starts committing to media, then
> we'll end up starving other IO anyway. This knob is a way to attempt
> to tame that.

Ah, makes perfect sense.  Thanks!

-Jeff