All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Block pull request for- 4.11-rc1
Date: Wed, 22 Feb 2017 11:52:05 -0700	[thread overview]
Message-ID: <2fa1c161-2893-438a-45f9-adbf5284ee71@kernel.dk> (raw)
In-Reply-To: <CA+55aFzK6j+jM8eHcMirbe2huV1RKEmqwrKTYH9YuXWBYZxsug@mail.gmail.com>

On 02/22/2017 11:45 AM, Linus Torvalds wrote:
> On Wed, Feb 22, 2017 at 10:41 AM, Jens Axboe <axboe@kernel.dk> wrote:
>>
>> The fact is that we have two different sets, until we can yank
>> the old ones. So I can't just ask one question, since the sets
>> aren't identical.
> 
> Bullshit.
> 
> I'm, saying: rip out the question ENTIRELY. For *both* cases.
> 
> If you cannot yourself give a good answer, then there's no f*cking way
> any user can give a good answer. So asking the question is totally and
> utterly pointless.
> 
> All it means is that different people will try different (in random
> ways) configurations, and the end result is random crap.
> 
> So get rid of those questions. Pick a default, and live with it. And
> if people complain about performance, fix the performance issue.
> 
> It's that simple.

No, it's not that simple at all. Fact is, some optimizations make sense
for some workloads, and some do not. CFQ works great for some cases, and
it works poorly for others, even if we try to make heuristics that enable
it to work well for all cases. Some optimizations are costly, that's
fine on certain types of hardware or maybe that's a trade off you want
to make. Or we end up with tons of settings for a single driver, that
does not reduce the configuration matrix at all.

By that logic, why do we have ANY config options outside of what drivers
to build? What should I set HZ at? RCU options? Let's default to ext4,
and kill off xfs? Or btrfs? slab/slob/slub/whatever?

Yes, that's taking the argument a bit more to the extreme, but it's the
same damn thing.

I'm fine with getting rid of the default selections, but we're NOT
going to be able to have just one scheduler for everything. We can
make sane defaults based on the hardware type.

-- 
Jens Axboe

  reply	other threads:[~2017-02-22 18:52 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-20  0:10 [GIT PULL] Block pull request for- 4.11-rc1 Jens Axboe
2017-02-20  1:09 ` Bart Van Assche
2017-02-20  1:09   ` Bart Van Assche
2017-02-20  1:15   ` Jens Axboe
2017-02-20  2:12     ` James Bottomley
2017-02-20  2:12       ` James Bottomley
2017-02-20  2:59       ` Jens Axboe
2017-02-20  3:02         ` Jens Axboe
2017-02-20  7:35     ` Christoph Hellwig
2017-02-20 16:16       ` Bart Van Assche
2017-02-20 16:16         ` Bart Van Assche
2017-02-20 16:32         ` Jens Axboe
2017-02-21  1:18           ` Bart Van Assche
2017-02-21  1:18             ` Bart Van Assche
2017-02-24 17:39           ` Bart Van Assche
2017-02-24 17:39             ` Bart Van Assche
2017-02-24 17:51             ` Jens Axboe
2017-02-24 19:43             ` Linus Torvalds
2017-02-24 20:00               ` Jens Axboe
2017-02-24 20:22                 ` Jens Axboe
2017-02-24 21:15                   ` Bart Van Assche
2017-02-24 21:15                     ` Bart Van Assche
2017-02-25 18:17                   ` hch
2017-02-25 18:22                     ` Jens Axboe
2017-02-21 19:11 ` Linus Torvalds
2017-02-21 19:34   ` Jens Axboe
2017-02-21 23:02   ` Linus Torvalds
2017-02-21 23:15     ` Jens Axboe
2017-02-21 23:23       ` Linus Torvalds
2017-02-22 18:14         ` Jens Axboe
2017-02-22 18:26           ` Linus Torvalds
2017-02-22 18:41             ` Jens Axboe
2017-02-22 18:45               ` Linus Torvalds
2017-02-22 18:52                 ` Jens Axboe [this message]
2017-02-22 18:56                   ` Linus Torvalds
2017-02-22 18:58                     ` Jens Axboe
2017-02-22 19:04                       ` Linus Torvalds
2017-02-22 21:29                         ` Jens Axboe
2017-02-22 18:42             ` Linus Torvalds
2017-02-22 18:44               ` Jens Axboe
2017-02-22 21:50                 ` Markus Trippelsdorf
2017-02-22 21:55                   ` Jens Axboe
2017-02-23  0:16                   ` Linus Torvalds

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=2fa1c161-2893-438a-45f9-adbf5284ee71@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.