linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Paolo Valente <paolo.valente@linaro.org>,
	Christoph Hellwig <hch@infradead.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Bart Van Assche <bart.vanassche@sandisk.com>,
	Jan Kara <jack@suse.cz>, Tejun Heo <tj@kernel.org>,
	linux-block@vger.kernel.org,
	Linux-Kernal <linux-kernel@vger.kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Mark Brown <broonie@kernel.org>, Hannes Reinecke <hare@suse.de>,
	Grant Likely <grant.likely@secretlab.ca>,
	James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler
Date: Fri, 28 Oct 2016 08:17:01 -0600	[thread overview]
Message-ID: <4948c47a-6e24-0a81-0564-5a61b6be35e9@kernel.dk> (raw)
In-Reply-To: <CAPDyKFqDqhMgpCN83P_dFf6wgfT3KCVT1Uw4kDMz620=3Hkj+A@mail.gmail.com>

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

  reply	other threads:[~2016-10-28 14:17 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-26  9:27 [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler Paolo Valente
2016-10-26  9:27 ` [PATCH 01/14] block, bfq: " Paolo Valente
2016-10-26  9:27 ` [PATCH 02/14] block, bfq: add full hierarchical scheduling and cgroups support Paolo Valente
2016-10-26  9:27 ` [PATCH 03/14] block, bfq: improve throughput boosting Paolo Valente
2016-10-26  9:27 ` [PATCH 04/14] block, bfq: modify the peak-rate estimator Paolo Valente
2016-10-26  9:27 ` [PATCH 05/14] block, bfq: add more fairness with writes and slow processes Paolo Valente
2016-10-26  9:27 ` [PATCH 06/14] block, bfq: improve responsiveness Paolo Valente
2016-10-26  9:28 ` [PATCH 07/14] block, bfq: reduce I/O latency for soft real-time applications Paolo Valente
2016-10-26  9:28 ` [PATCH 08/14] block, bfq: preserve a low latency also with NCQ-capable drives Paolo Valente
2016-10-26  9:28 ` [PATCH 09/14] block, bfq: reduce latency during request-pool saturation Paolo Valente
2016-10-26 10:19 ` [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler Christoph Hellwig
2016-10-26 11:34   ` Jan Kara
2016-10-26 15:05     ` Bart Van Assche
2016-10-26 15:13       ` Arnd Bergmann
2016-10-26 15:29         ` Christoph Hellwig
2016-10-26 15:32           ` Jens Axboe
2016-10-26 16:04             ` Paolo Valente
2016-10-26 16:12               ` Jens Axboe
2016-10-27  9:26                 ` Jan Kara
2016-10-27 14:34                   ` Grozdan
2016-10-27 15:55                     ` Heinz Diehl
2016-10-27 16:28                     ` Jens Axboe
2016-10-27 16:26                   ` Jens Axboe
2016-10-28  7:59                     ` Jan Kara
2016-10-28 14:10                       ` Jens Axboe
2016-10-27 17:32                 ` Ulf Hansson
2016-10-27 17:43                   ` Jens Axboe
2016-10-27 18:13                     ` Ulf Hansson
2016-10-27 18:21                       ` Jens Axboe
2016-10-27 19:34                         ` Ulf Hansson
2016-10-27 21:08                           ` Jens Axboe
2016-10-27 22:27                             ` Linus Walleij
2016-10-28  9:32                               ` Linus Walleij
2016-10-28 14:22                                 ` Jens Axboe
2016-10-28 20:38                                   ` Linus Walleij
2016-10-28 15:29                                 ` Christoph Hellwig
2016-10-28 21:09                                   ` Linus Walleij
2016-10-28 15:30                                 ` Jens Axboe
2016-10-28 15:58                                   ` Bartlomiej Zolnierkiewicz
2016-10-28 16:05                                   ` Arnd Bergmann
2016-10-28 17:17                                     ` Mark Brown
2016-10-28 14:07                               ` Jens Axboe
2016-10-28  6:36                             ` Ulf Hansson
2016-10-28 14:17                               ` Jens Axboe [this message]
2016-10-28 17:12                                 ` Mark Brown
2016-10-27 19:41                         ` Mark Brown
2016-10-27 19:45                           ` Christoph Hellwig
2016-10-27 22:01                             ` Mark Brown
2016-10-28 12:07                       ` Arnd Bergmann
2016-10-28 12:17                         ` Richard Weinberger
2016-10-29  5:38                 ` Paolo Valente
2016-10-29 13:12                   ` Bart Van Assche
2016-10-29 14:12                   ` Jens Axboe
2016-10-30  3:06                     ` Paolo Valente
2016-10-26 12:37   ` Paolo Valente
2016-10-29 17:08 Manuel Krause
2016-10-30 17:48 Manuel Krause

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4948c47a-6e24-0a81-0564-5a61b6be35e9@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=arnd@arndb.de \
    --cc=bart.vanassche@sandisk.com \
    --cc=broonie@kernel.org \
    --cc=grant.likely@secretlab.ca \
    --cc=hare@suse.de \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linus.walleij@linaro.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paolo.valente@linaro.org \
    --cc=tj@kernel.org \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).