[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aItD6juaFaPncYka@fedora>
Date: Thu, 31 Jul 2025 18:22:34 +0800
From: Ming Lei <ming.lei@...hat.com>
To: Yu Kuai <yukuai1@...weicloud.com>
Cc: dlemoal@...nel.org, hare@...e.de, jack@...e.cz, tj@...nel.org,
josef@...icpanda.com, axboe@...nel.dk, cgroups@...r.kernel.org,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
yi.zhang@...wei.com, yangerkun@...wei.com, johnny.chenyi@...wei.com,
"yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH v2 0/5] blk-mq-sched: support request batch dispatching
for sq elevator
On Thu, Jul 31, 2025 at 05:33:24PM +0800, Yu Kuai wrote:
> Hi,
>
> 在 2025/07/31 17:25, Ming Lei 写道:
> > On Thu, Jul 31, 2025 at 04:42:10PM +0800, Yu Kuai wrote:
> > > Hi,
> > >
> > > 在 2025/07/31 16:18, Ming Lei 写道:
> > > > batch dispatch may hurt io merge performance which is important for
> > > > elevator, so please provide test data on real HDD. & SSD., instead of
> > > > null_blk only, and it can be perfect if merge sensitive workload
> > > > is evaluated.
> > >
> > > Ok, I'll provide test data on HDD and SSD that I have for now.
> > >
> > > For the elevator IO merge case, what I have in mind is that we issue
> > > small sequential IO one by one with multiple contexts, so that bios
> > > won't be merged in plug, and this will require IO issue > IO done, is
> > > this case enough?
> >
> > Long time ago, I investigated one such issue which is triggered in qemu
> > workload, but not sure if I can find it now.
> >
> > Also many scsi devices may easily run into queue busy, then scheduler merge
> > starts to work, and it may perform worse if you dispatch more in this
> > situation.
>
> I think we won't dispatch more in this case, on the one hand we will get
> budgets first, to make sure never dispatch more than queue_depth; on the
OK.
> onther hand, in the case hctx->dispatch_busy is set, we still fallback
> to the old case to dispatch one at a time;
hctx->dispatch_busy is lockless, all request may get dispatched before
hctx->dispatch_busy is set.
Thanks,
Ming
Powered by blists - more mailing lists