linux-kernel - Re: Fwd: [PATCH V3 00/11] block-throttle: add .high limit

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: <20161014164036.GA6320@mtj.duckdns.org>
Date:   Fri, 14 Oct 2016 12:40:36 -0400
From:   Tejun Heo <tj@...nel.org>
To:     Kyle Sanderson <kyle.leet@...il.com>
Cc:     jmoyer@...hat.com, Paolo Valente <paolo.valente@...more.it>,
        Linux-Kernal <linux-kernel@...r.kernel.org>,
        Mark Brown <broonie@...nel.org>, linux-block@...r.kernel.org,
        Shaohua Li <shli@...com>, Jens Axboe <axboe@...com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Vivek Goyal <vgoyal@...hat.com>, Kernel-team@...com,
        Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: Fwd: [PATCH V3 00/11] block-throttle: add .high limit

Hello, Kyle.

On Sat, Oct 08, 2016 at 06:15:14PM -0700, Kyle Sanderson wrote:
> How is this even a discussion when hard numbers, and trying any
> reproduction case easily reproduce the issues that CFQ causes. Reading
> this thread, and many others only grows not only my disappointment,
> but whenever someone launches kterm or scrot and their machine
> freezes, leaves a selective few individuals completely responsible for
> this. Help those users, help yourself, help Linux.

So, just to be clear.  I wasn't arguing against bfq replacing cfq (or
anything along that line) but that proportional control, as
implemented, would be too costly for many use cases and thus we need
something along the line of what Shaohua is proposing.

FWIW, it looks like the only way we can implement proportional control
on highspeed ssds with acceptable overhead is somehow finding a way to
calculate the cost of each IO and throttle IOs according to that while
controlling for latency as necessary.  Slice scheduling with idling
seems too expensive with highspeed devices with high io depth.

Thanks.

-- 
tejun