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
WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@kernel.dk> To: Sagi Grimberg <sagi@grimberg.me>, Rachit Agarwal <rach4x0r@gmail.com>, Christoph Hellwig <hch@lst.de> Cc: Qizhe Cai <qc228@cornell.edu>, Rachit Agarwal <ragarwal@cornell.edu>, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, Ming Lei <ming.lei@redhat.com>, linux-block@vger.kernel.org, Midhul Vuppalapati <mvv25@cornell.edu>, Jaehyun Hwang <jaehyun.hwang@cornell.edu>, Rachit Agarwal <ragarwal@cs.cornell.edu>, Keith Busch <kbusch@kernel.org>, Sagi Grimberg <sagi@lightbitslabs.com> 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 _______________________________________________ Linux-nvme mailing list Linux-nvme@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2020-11-13 21:03 UTC|newest] Thread overview: 29+ 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 14:07 ` Rachit Agarwal 2020-11-12 18:02 ` Jens Axboe 2020-11-12 18:02 ` Jens Axboe 2020-11-13 20:34 ` Sagi Grimberg 2020-11-13 20:34 ` Sagi Grimberg 2020-11-13 21:03 ` Jens Axboe [this message] 2020-11-13 21:03 ` Jens Axboe 2020-11-13 21:23 ` Sagi Grimberg 2020-11-13 21:23 ` Sagi Grimberg 2020-11-13 21:26 ` Jens Axboe 2020-11-13 21:26 ` Jens Axboe 2020-11-13 21:36 ` Sagi Grimberg 2020-11-13 21:36 ` Sagi Grimberg 2020-11-13 21:44 ` Jens Axboe 2020-11-13 21:44 ` Jens Axboe 2020-11-13 21:56 ` Sagi Grimberg 2020-11-13 21:56 ` Sagi Grimberg [not found] ` <CAKeUqKKHg1wD19pnwJEd8whubnuGVic_ZhDjebaq3kKmY9TtsQ@mail.gmail.com> 2020-11-30 19:20 ` Sagi Grimberg 2020-11-30 19:20 ` Sagi Grimberg 2020-12-28 14:28 ` Rachit Agarwal 2021-01-11 18:15 ` Rachit Agarwal 2021-01-11 18:15 ` Rachit Agarwal 2020-11-16 8:41 ` Ming Lei 2020-11-16 8:41 ` Ming Lei 2020-11-13 14:59 ` Ming Lei 2020-11-13 14:59 ` Ming Lei 2020-11-13 20:58 ` Sagi Grimberg 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: linkBe 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.