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
| ||
|
Date: Fri, 14 Oct 2016 19:13:41 +0200 From: Paolo Valente <paolo.valente@...more.it> To: Tejun Heo <tj@...nel.org> Cc: Kyle Sanderson <kyle.leet@...il.com>, jmoyer@...hat.com, 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: [PATCH V3 00/11] block-throttle: add .high limit > Il giorno 14 ott 2016, alle ore 18:40, Tejun Heo <tj@...nel.org> ha scritto: > > 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. > Sorry for dropping in all the times, but the vision that you and some other guys propose seems to miss some important piece (unless, now or then, you will patiently prove me wrong, or I will finally understand on my own why I'm wrong). You are of course right: bfq, as a component of blk, and above all, as a sort of derivative of CFQ (and of its overhead), has currently too high a overhead to handle more than 10-20K IOPS. That said, your 'thus' seems a little too strong: "bfq does not yet handle fast SSDs, thus we need something else". What about the millions of devices (and people) still within 10-20 K IOPS, and experiencing awful latencies and lack of bandwidth guarantees? For certain systems or applications, it isn't even just a "buy a fast SSD" matter, but a technological constraint. > FWIW, it looks like the only way we can implement proportional control > on highspeed ssds with acceptable overhead Maybe not: as I wrote to Viveck in a previous reply, containing pointers to documentation, we have already achieved twenty millions of decisions per second with a prototype driving existing proportional-share packet schedulers (essentially without modifications). > 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. > Yes, that's absolutely true. I'm already thinking about an idleless solution. As I already wrote, I'm willing to help with scheduling in blk-mq. I hope there will be the opportunity to find some way to go at KS. Thanks, Paolo > Thanks. > > -- > tejun -- Paolo Valente Algogroup Dipartimento di Scienze Fisiche, Informatiche e Matematiche Via Campi 213/B 41125 Modena - Italy http://algogroup.unimore.it/people/paolo/
Powered by blists - more mailing lists