Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932756AbcJNROD convert rfc822-to-8bit (ORCPT ); Fri, 14 Oct 2016 13:14:03 -0400 Received: from smtp26.sms.unimo.it ([155.185.44.26]:47308 "EHLO smtp26.sms.unimo.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753434AbcJNRNw (ORCPT ); Fri, 14 Oct 2016 13:13:52 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [PATCH V3 00/11] block-throttle: add .high limit From: Paolo Valente In-Reply-To: <20161014164036.GA6320@mtj.duckdns.org> Date: Fri, 14 Oct 2016 19:13:41 +0200 Cc: Kyle Sanderson , jmoyer@redhat.com, Linux-Kernal , Mark Brown , linux-block@vger.kernel.org, Shaohua Li , Jens Axboe , Linus Walleij , Vivek Goyal , Kernel-team@fb.com, Ulf Hansson Content-Transfer-Encoding: 8BIT Message-Id: <6B4FE5ED-75BD-4AD8-B0FA-B452FB631BE8@unimore.it> References: <278BCC7B-ED58-4FDF-9243-FAFC3F862E4D@unimore.it> <20161004172852.GB73678@anikkar-mbp.local.dhcp.thefacebook.com> <20161004185413.GF4205@htj.duckdns.org> <20161004191427.GG4205@htj.duckdns.org> <20161004202754.GJ4205@htj.duckdns.org> <20161014164036.GA6320@mtj.duckdns.org> To: Tejun Heo X-Mailer: Apple Mail (2.3124) UNIMORE-X-SA-Score: -2.9 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2701 Lines: 76 > Il giorno 14 ott 2016, alle ore 18:40, Tejun Heo 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/