Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760605AbcJ1ORG (ORCPT ); Fri, 28 Oct 2016 10:17:06 -0400 Received: from mail-yw0-f179.google.com ([209.85.161.179]:36022 "EHLO mail-yw0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756460AbcJ1ORE (ORCPT ); Fri, 28 Oct 2016 10:17:04 -0400 Subject: Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler To: Ulf Hansson References: <1477474082-2846-1-git-send-email-paolo.valente@linaro.org> <20161026113443.GA13587@quack2.suse.cz> <4ed3e291-b3e5-5ee3-6838-58644bd3d99b@sandisk.com> <12386463.fJy0cVexVD@wuerfel> <20161026152955.GA21262@infradead.org> <3ebadbb8-9ac2-851a-66f9-c9db25713695@kernel.dk> <38156FA7-9A66-44DC-8D0C-28F149D1E49B@linaro.org> <09fc1e06-3fd6-b13d-0dd9-0edfb55b01d1@kernel.dk> <15ee2d0e-2d3a-81e2-9f83-f875e41bf388@kernel.dk> <1ac9b794-7e7f-0748-e4c8-a13034aecbc3@kernel.dk> Cc: Paolo Valente , Christoph Hellwig , Arnd Bergmann , Bart Van Assche , Jan Kara , Tejun Heo , linux-block@vger.kernel.org, Linux-Kernal , Linus Walleij , Mark Brown , Hannes Reinecke , Grant Likely , James Bottomley From: Jens Axboe Message-ID: <4948c47a-6e24-0a81-0564-5a61b6be35e9@kernel.dk> Date: Fri, 28 Oct 2016 08:17:01 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1875 Lines: 46 On 10/28/2016 12:36 AM, Ulf Hansson wrote: > [...] > >> >>> Moreover, I am still trying to understand what's the big deal to why >>> you say no to BFQ as a legacy scheduler. Ideally it shouldn't cause >>> you any maintenance burden and it doesn't make the removal of the >>> legacy blk layer any more difficult, right? >> >> >> Not sure I can state it much clearer. It's a new scheduler, and a >> complicated one at that. It WILL carry a maintenance burden. And I'm > > Really? Either you maintain the code or not. And if Paolo would do it, > then your are off the hook! Are you trying to be deliberately obtuse? If so, good job. I'd advise you to look into how code in the kernel is maintained in general. A maintenance burden exists for code A, but it also carries over to the subsystem it is under, and the kernel in general. Adding code is never free. >> really not that interested in adding such a burden for something that >> will be defunct as soon as the single queue blk-mq version is done. >> Additionally, if we put BFQ in right now, the motivation to do the real >> work will be gone. > > You have been pushing Paolo in different directions throughout the > years with his work in BFQ, wasting lots of his time/effort. I have not. Various entities have advised Paolo approach it in various ways. We've had blk-mq for 3 years now, my position should have been pretty clear on that. > You have not given him any credibility for his work in BFQ and now you > point him yet in another direction. I don't even know what that means. But I'm not pointing him in a new direction. Ulf, I'm done discussing with you. I've made my position clear, yet you continue to beat on a dead horse. As far as I'm concerned, there's nothing further to discuss here. I'll be happy to discuss when there's some meat on the bone (ie code). Until then, EOD. -- Jens Axboe