On 11/21/24 01:12, Jens Axboe wrote:
On 11/20/24 4:56 PM, Pavel Begunkov wrote:
On 11/20/24 22:14, David Wei wrote:
...
One thing that is not so nice is that now we have this handling and
checks in the hot path, and __io_run_local_work_loop() most likely
gets uninlined.
I don't think that really matters, it's pretty light. The main overhead
in this function is not the call, it's reordering requests and touching
cachelines of the requests.
I think it's pretty light as-is and actually looks pretty good. It's
It could be light, but the question is importance / frequency of
the new path. If it only happens rarely but affects a high 9,
then it'd more sense to optimise it from the common path.
also similar to how sqpoll bites over longer task_work lines, and
arguably a mistake that we allow huge depths of this when we can avoid
it with deferred task_work.
I wonder, can we just requeue it via task_work again? We can even
add a variant efficiently adding a list instead of a single entry,
i.e. local_task_work_add(head, tail, ...);
I think that can only work if we change work_llist to be a regular list
with regular locking. Otherwise it's a bit of a mess with the list being
Dylan once measured the overhead of locks vs atomics in this
path for some artificial case, we can pull the numbers up.
reordered, and then you're spending extra cycles on potentially
reordering all the entries again.
That sucks, I agree, but then it's same question of how often
it happens.
--
Pavel Begunkov
