How to prevent nonvoluntary_ctxt_switches on SQPOLL thread? IORING_REGISTER_IOWQ_AFF not working on Linux 6.3.2 #884
sharpobject
started this conversation in
General
Replies: 1 comment
-
After trying random things in desperation, I've discovered that the noisier iou-wrk thread is associated with disk i/o, so I can avoid spawning it by doing no disk i/o from this ring. (For now that means I have no logs, but later today I can send logs over a userspace spsc queue to another thread and output them with write(2) or whatever). The less noisy iou-wrk thread still causes about 20 context switches per second to the precious iou-sqp thread though, and it would still be swell to reduce that to 0. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello,
Although I don't know whether this is possible, I would like ideally like the kernel-side busy polling thread to always be busy polling. I am using cpuset to assign threads to cores other than the SQPOLL thread. I am assigning the SQPOLL thread to a core when setting up my io_uring instance. I am assigning the iou-wrk threads to a core by calling io_uring_register with IORING_REGISTER_IOWQ_AFF. My application enters steady state soon after startup with the main thread having performed (in this example) 580 context switches, but the SQPOLL thread continues to perform ~500 context switches per second indefinitely because the iou-wrk thread is scheduled to the same core (disregarding the prior io_uring_register!) and apparently cannot ever be moved to another core.
I'm running this on Linux 6.3.2 on AWS with whatever virtualization AWS normally uses. I'm not sure which details matter here so I'm trying to be thorough.
I previously observed the same behavior on Linux 5.17.0.
Here's my version of linux
Here's a lightly redacted strace output of my application
Here's some information about the threads in my application in one run. Thread 5116 is my userspace busy-polling thread. Thread 5117 is my kernel busy polling thread. Thread 5118 is an offload thread for doing DNS because async DNS is hard. Threads 5119 and 5463 are iou-wrk threads whose CPU affinity is all CPUs even though I specifically asked for it to be only one CPU and which always get scheduled to the CPU that I am trying to reserve for thread 5117 even though their affinity says they could go anywhere and 2 other CPUs are idle.
As you can see my kernel busy polling thread 5117 is being nonvoluntary_ctxt_switched quite often, apparently by thread 5119.
Beta Was this translation helpful? Give feedback.
All reactions