Message ID | 20241120221452.3762588-1-dw@davidwei.uk (mailing list archive) |
---|---|
Headers | show |
Series | limit local tw done | expand |
On 11/20/24 3:14 PM, David Wei wrote: > Currently when running local tw it will eagerly try and complete all > available work. When there is a burst of work coming in, the list of > work in work_llist may be much larger than the requested batch count > wait_nr. Doing all of the work eagerly may cause latency issues for some > applications that do not want to spend so much time in the kernel. > > Limit the amount of local tw done to the max of 20 (a heuristic) or > wait_nr. This then does not require any userspace changes. > > Many applications will submit and wait with wait_nr = 1 to mean "wait > for _at least_ 1 completion, but do more work if available". This used > to mean "all work" but now that is capped to 20 requests. If users want > more work batching, then they can set wait_nr to > 20. Looks good to me!
On Wed, 20 Nov 2024 14:14:50 -0800, David Wei wrote: > Currently when running local tw it will eagerly try and complete all > available work. When there is a burst of work coming in, the list of > work in work_llist may be much larger than the requested batch count > wait_nr. Doing all of the work eagerly may cause latency issues for some > applications that do not want to spend so much time in the kernel. > > Limit the amount of local tw done to the max of 20 (a heuristic) or > wait_nr. This then does not require any userspace changes. > > [...] Applied, thanks! [1/2] io_uring: add io_local_work_pending() commit: 40cfe553240b32333b42652370ef5232e6ac59e1 [2/2] io_uring: limit local tw done commit: f46b9cdb22f7a167c36b6bcddaef7e8aee2598fa Best regards,