From: Sagi Grimberg <sagi@grimberg.me>
To: Jens Axboe <axboe@kernel.dk>, Rachit Agarwal <rach4x0r@gmail.com>,
Christoph Hellwig <hch@lst.de>
Cc: linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-kernel@vger.kernel.org, Keith Busch <kbusch@kernel.org>,
Ming Lei <ming.lei@redhat.com>,
Jaehyun Hwang <jaehyun.hwang@cornell.edu>,
Qizhe Cai <qc228@cornell.edu>,
Midhul Vuppalapati <mvv25@cornell.edu>,
Rachit Agarwal <ragarwal@cs.cornell.edu>,
Sagi Grimberg <sagi@lightbitslabs.com>,
Rachit Agarwal <ragarwal@cornell.edu>
Subject: Re: [PATCH] iosched: Add i10 I/O Scheduler
Date: Fri, 13 Nov 2020 13:36:16 -0800 [thread overview]
Message-ID: <cbe18a3d-8a6b-e775-81bb-3b3f11045183@grimberg.me> (raw)
In-Reply-To: <c4cb66f6-8a66-7973-dc03-0f4f61d0a1e4@kernel.dk>
>> But if you think this has a better home, I'm assuming that the guys
>> will be open to that.
>
> Also see the reply from Ming. It's a balancing act - don't want to add
> extra overhead to the core, but also don't want to carry an extra
> scheduler if the main change is really just variable dispatch batching.
> And since we already have a notion of that, seems worthwhile to explore
> that venue.
I agree,
The main difference is that this balancing is not driven from device
resource pressure, but rather from an assumption of device specific
optimization (and also with a specific optimization target), hence a
scheduler a user would need to opt-in seemed like a good compromise.
But maybe Ming has some good ideas on a different way to add it..
next prev parent reply other threads:[~2020-11-13 21:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-12 14:07 [PATCH] iosched: Add i10 I/O Scheduler Rachit Agarwal
2020-11-12 18:02 ` Jens Axboe
2020-11-13 20:34 ` Sagi Grimberg
2020-11-13 21:03 ` Jens Axboe
2020-11-13 21:23 ` Sagi Grimberg
2020-11-13 21:26 ` Jens Axboe
2020-11-13 21:36 ` Sagi Grimberg [this message]
2020-11-13 21:44 ` Jens Axboe
2020-11-13 21:56 ` Sagi Grimberg
[not found] ` <CAKeUqKKHg1wD19pnwJEd8whubnuGVic_ZhDjebaq3kKmY9TtsQ@mail.gmail.com>
2020-11-30 19:20 ` Sagi Grimberg
[not found] ` <CAKeUqKK3yykq8LNv1CCHZTHSz1=bzBaCwVQmi6bhpbYzqVJsqQ@mail.gmail.com>
2021-01-11 18:15 ` Rachit Agarwal
2020-11-16 8:41 ` Ming Lei
2020-11-13 14:59 ` Ming Lei
2020-11-13 20:58 ` Sagi Grimberg
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=cbe18a3d-8a6b-e775-81bb-3b3f11045183@grimberg.me \
--to=sagi@grimberg.me \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=jaehyun.hwang@cornell.edu \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=ming.lei@redhat.com \
--cc=mvv25@cornell.edu \
--cc=qc228@cornell.edu \
--cc=rach4x0r@gmail.com \
--cc=ragarwal@cornell.edu \
--cc=ragarwal@cs.cornell.edu \
--cc=sagi@lightbitslabs.com \
/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).