Hi,
在 2024/12/20 3:25, Bart Van Assche 写道:
On 12/18/24 5:21 PM, Yu Kuai wrote:
Hi,
在 2024/12/19 2:00, Bart Van Assche 写道:
On 12/17/24 5:14 PM, Yu Kuai wrote:
I can't make this read-write, because set lower value will cause
problems for existing elevator, because wake_batch has to be
updated as well.
Should the request queue perhaps be frozen before wake_batch is updated?
Yes, we should. The good thing is for now it's frozen already:
- update nr_requests context;
- switch elevator;
However, if you mean do this while writing async_depth, freeze queue
is not enough, we have to ping all the hctx as well by q->sysfs_lock,
which is not possible.
Or if you mean do this while write the new min_async_depth, then we have
to update wat_batch for all the queues in the system, too crazy for
me...
Should min_async_depth perhaps be a request queue attribute instead of
an mq-deadline I/O scheduler attribute?
Yes, I think this make sense, at least kyber and deadline can both
benefit from this. And I might must add a new async_depth_updated() api
to the elevator ops.
Thanks,
Kuai
Thanks,
Bart.
.
