linux-kernel - Re: [PATCH IMPROVEMENT] block, bfq: increase threshold to deem I/O as random

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] [day] [month] [year] [list]

Date:   Fri, 5 Jan 2018 09:24:15 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     Paolo Valente <paolo.valente@...aro.org>
Cc:     linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        ulf.hansson@...aro.org, broonie@...nel.org,
        linus.walleij@...aro.org, angeloruocco90@...il.com,
        bfq-iosched@...glegroups.com
Subject: Re: [PATCH IMPROVEMENT] block, bfq: increase threshold to deem I/O as
 random

On 12/20/17 9:27 AM, Paolo Valente wrote:
> If two processes do I/O close to each other, i.e., are cooperating
> processes in BFQ (and CFQ'S) nomenclature, then BFQ merges their
> associated bfq_queues, so as to get sequential I/O from the union of
> the I/O requests of the processes, and thus reach a higher
> throughput. A merged queue is then split if its I/O stops being
> sequential. In this respect, BFQ deems the I/O of a bfq_queue as
> (mostly) sequential only if less than 4 I/O requests are random, out
> of the last 32 requests inserted into the queue.
> 
> Unfortunately, extensive testing (with the interleaved_io benchmark of
> the S suite [1], and with real applications spawning cooperating
> processes) has clearly shown that, with such a low threshold, only a
> rather low I/O throughput may be reached when several cooperating
> processes do I/O. In particular, the outcome of each test run was
> bimodal: if queue merging occurred and was stable during the test,
> then the throughput was close to the peak rate of the storage device,
> otherwise the throughput was arbitrarily low (usually around 1/10 of
> the peak rate with a rotational device). The probability to get the
> unlucky outcomes grew with the number of cooperating processes: it was
> already significant with 5 processes, and close to one with 7 or more
> processes.
> 
> The cause of the low throughput in the unlucky runs was that the
> merged queues containing the I/O of these cooperating processes were
> soon split, because they contained more random I/O requests than those
> tolerated by the 4/32 threshold, but
> - that I/O would have however allowed the storage device to reach
>   peak throughput or almost peak throughput;
> - in contrast, the I/O of these processes, if served individually
>   (from separate queues) yielded a rather low throughput.
> 
> So we repeated our tests with increasing values of the threshold,
> until we found the minimum value (19) for which we obtained maximum
> throughput, reliably, with at least up to 9 cooperating
> processes. Then we checked that the use of that higher threshold value
> did not cause any regression for any other benchmark in the suite [1].
> This commit raises the threshold to such a higher value.

Applied for 4.16, thanks.

-- 
Jens Axboe