Hi, Bart
在 2024/12/11 4:33, Bart Van Assche 写道:
If so, following are the options that I can think of to fix this:
1) make async_depth read-only, if 75% tags will hurt performance in some
cases, user can increase nr_requests to prevent it.
2) refactor elevator sysfs api, remove eq->sysfs_lock and replace it
with q->sysfs_lock, so deadline_async_depth_store() will be protected
against changing hctxs, and min_shallow_depth can be updated here.
3) other options?
Another option is to remove the ability to configure async_depth. If it
is too much trouble to get the implementation right without causing
regressions for existing workloads, one possibility is to remove support
for restricting the number of asynchronous requests in flight.
If you agree, I'll use following option in the next version:
4) set min_async_depth to 64 (after treating min_shallow_depth for the
whole sbitmap instead of one word).
The good thing is that user can still set async_depth without changing
wake_batch, the side effect is that async_depth can't be used if
nr_requests <= 64;
Thanks,
Kuai
