Re: [PATCH RFC v2 0/5] blk-mq-sched: support request batch dispatching for sq elevator

[Yu Kuai]

Hi,

在 2025/06/16 15:37, Damien Le Moal 写道:
> On 6/16/25 16:22, Yu Kuai wrote:
> > I agree that lock contention here will not affect HDD performance.
> > What I suspect the difference in my environment is that the order of rqs
> > might be changed from elevator dispatching them and the disk handling
> > them.
> >
> > For example, the order can be easily revised if more than one context
> > dispatch one request at a time:
> >
> > t1:
> >
> > lock
> > rq1 = dd_dispatch_request
> > unlock
> > 			t2:
> > 			lock
> > 			rq2 = dd_dispatch_request
> > 			unlock
> >
> > lock
> > rq3 = dd_dispatch_request
> > unlock
> >
> > 			lock
> > 			rq4 = dd_dispatch_request
> > 			unlock
> >
> > //rq1,rq3 issue to disk
> > 			// rq2, rq4 issue to disk
> >
> > In this case, the elevator dispatch order is rq 1-2-3-4, however,
> > such order in disk is rq 1-3-2-4.
> >
> > And with batch requests dispatch, will this less likely to happen?
>
> If you are running a write test with the HDD write cache enabled, such
> reordering will most liley not matter at all. Running the same workload with
> "none" and I get the same IOPS for writes.
>
> Check your disk. If you do have the HDD write cache disabled, then sure, the
> order will matter more depending on how your drive handles WCD writes (recent
> drives have very similar performance with WCE and WCD).
Thanks for the explanation, I'll test more workload on more disks, and
of corese, explain details more in the formal version as you suggested.

Kuai