summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJens Axboe <axboe@kernel.dk>2026-04-27 23:42:18 +0300
committerJens Axboe <axboe@kernel.dk>2026-04-29 01:09:02 +0300
commitdf8599ee18c0e5fe343ffe0b4c379636b8bb839a (patch)
tree4d55ed7ab1953e7bdc098c166e38d627e22a29c2
parent7deba791ad495ce1d7921683f4f7d1190fa210d1 (diff)
downloadlinux-df8599ee18c0e5fe343ffe0b4c379636b8bb839a.tar.xz
io_uring/napi: cap busy_poll_to 10 msec
Currently there's no cap on the maximum amount of time that napi is allowed to poll if no events are found, which can lead to kernel complaints on a task being stuck as there's no conditional rescheduling done within that loop. Just cap it to 10 msec in total, that's already way above any kind of sane value that will reap any benefits, yet low enough that it's nowhere near being able to trigger preemption complaints. Fixes: 8d0c12a80cde ("io-uring: add napi busy poll support") Signed-off-by: Jens Axboe <axboe@kernel.dk>
-rw-r--r--io_uring/napi.c2
1 files changed, 2 insertions, 0 deletions
diff --git a/io_uring/napi.c b/io_uring/napi.c
index 4a10de03e426..8d68366a4b90 100644
--- a/io_uring/napi.c
+++ b/io_uring/napi.c
@@ -276,6 +276,8 @@ static int io_napi_register_napi(struct io_ring_ctx *ctx,
/* clean the napi list for new settings */
io_napi_free(ctx);
WRITE_ONCE(ctx->napi_track_mode, napi->op_param);
+ /* cap NAPI at 10 msec of spin time */
+ napi->busy_poll_to = min(10000, napi->busy_poll_to);
WRITE_ONCE(ctx->napi_busy_poll_dt, napi->busy_poll_to * NSEC_PER_USEC);
WRITE_ONCE(ctx->napi_prefer_busy_poll, !!napi->prefer_busy_poll);
return 0;