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
