From: Jens Axboe <axboe@kernel.dk>
To: Sagi Grimberg <sagi@grimberg.me>,
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 14:03:05 -0700 [thread overview]
Message-ID: <fd12993a-bcb7-7b45-5406-61da1979d49d@kernel.dk> (raw)
In-Reply-To: <da0c7aea-d917-4f3a-5136-89c30d12ba1f@grimberg.me>
On 11/13/20 1:34 PM, Sagi Grimberg wrote:
>
>> I haven't taken a close look at the code yet so far, but one quick note
>> that patches like this should be against the branches for 5.11. In fact,
>> this one doesn't even compile against current -git, as
>> blk_mq_bio_list_merge is now called blk_bio_list_merge.
>
> Ugh, I guess that Jaehyun had this patch bottled up and didn't rebase
> before submitting.. Sorry about that.
>
>> In any case, I did run this through some quick peak testing as I was
>> curious, and I'm seeing about 20% drop in peak IOPS over none running
>> this. Perf diff:
>>
>> 10.71% -2.44% [kernel.vmlinux] [k] read_tsc
>> 2.33% -1.99% [kernel.vmlinux] [k] _raw_spin_lock
>
> You ran this with nvme? or null_blk? I guess neither would benefit
> from this because if the underlying device will not benefit from
> batching (at least enough for the extra cost of accounting for it) it
> will be counter productive to use this scheduler.
This is nvme, actual device. The initial posting could be a bit more
explicit on the use case, it says:
"For NVMe SSDs, the i10 I/O scheduler achieves ~60% improvements in
terms of IOPS per core over "noop" I/O scheduler."
which made me very skeptical, as it sounds like it's raw device claims.
Does beg the question of why this is a new scheduler then. It's pretty
basic stuff, something that could trivially just be added a side effect
of the core (and in fact we have much of it already). Doesn't really seem
to warrant a new scheduler at all. There isn't really much in there.
>>> [5] https://github.com/i10-kernel/upstream-linux/blob/master/dss-evaluation.pdf
>>
>> Was curious and wanted to look it up, but it doesn't exist.
>
> I think this is the right one:
> https://github.com/i10-kernel/upstream-linux/blob/master/i10-evaluation.pdf
>
> We had some back and forth around the naming, hence this was probably
> omitted.
That works, my local results were a bit worse than listed in there though.
And what does this mean:
"We note that Linux I/O scheduler introduces an additional kernel worker
thread at the I/O dispatching stage"
It most certainly does not for the common/hot case.
--
Jens Axboe
next prev parent reply other threads:[~2020-11-13 21:03 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 [this message]
2020-11-13 21:23 ` Sagi Grimberg
2020-11-13 21:26 ` Jens Axboe
2020-11-13 21:36 ` Sagi Grimberg
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=fd12993a-bcb7-7b45-5406-61da1979d49d@kernel.dk \
--to=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@grimberg.me \
--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).