From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: Linus Walleij , Greg KH References: <20160916082415.GA15313@kroah.com> From: Bart Van Assche Message-ID: Date: Fri, 16 Sep 2016 11:10:54 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Cc: Bartlomiej Zolnierkiewicz , ksummit-discuss@lists.linux-foundation.org, Jens Axboe , hare@suse.de, Tejun Heo , osandov@osandov.com, Christoph Hellwig Subject: Re: [Ksummit-discuss] [TECH TOPIC] Addressing long-standing high-latency problems related to I/O List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 09/16/2016 10:59 AM, Linus Walleij wrote: > - What will subsystems (especially my pet peeve about MMC/SD > which is single-queue by nature) that experience a performance > regression with a switch to mq do? Not switch until mq has a > scheduling policy? Switch and suck up the performance regression, > multiplied by the number of Android handheld devices on the > planet? > > I only have handwavy arguments about the latter being the > case which is why I'm working on a patch to MMC/SD to > switch to mq as an RFT. It's taking some time though, alas > I'm not very smart. Hello Linus, What was your reference when comparing blk-mq MMC/SD performance with the current implementation? Which I/O scheduler was used when measuring performance with the traditional block layer? If it was not noop, how does blk-mq performance of MMC/SD compare to the performance of the current implementation with noop scheduler? Thanks, Bart.