[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cbe18a3d-8a6b-e775-81bb-3b3f11045183@grimberg.me>
Date: Fri, 13 Nov 2020 13:36:16 -0800
From: Sagi Grimberg <sagi@...mberg.me>
To: Jens Axboe <axboe@...nel.dk>, Rachit Agarwal <rach4x0r@...il.com>,
Christoph Hellwig <hch@....de>
Cc: linux-block@...r.kernel.org, linux-nvme@...ts.infradead.org,
linux-kernel@...r.kernel.org, Keith Busch <kbusch@...nel.org>,
Ming Lei <ming.lei@...hat.com>,
Jaehyun Hwang <jaehyun.hwang@...nell.edu>,
Qizhe Cai <qc228@...nell.edu>,
Midhul Vuppalapati <mvv25@...nell.edu>,
Rachit Agarwal <ragarwal@...cornell.edu>,
Sagi Grimberg <sagi@...htbitslabs.com>,
Rachit Agarwal <ragarwal@...nell.edu>
Subject: Re: [PATCH] iosched: Add i10 I/O Scheduler
>> 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..
Powered by blists - more mailing lists