On Fri, Nov 18, 2022 at 05:47:58AM +0100, Hans Petter Selasky wrote: > Hi, > > I'm doing some work with audio and have noticed some problems with the > ULE scheduler. I have a program that generate audio based on > key-presses. When no keys are pressed, the load is near 0%, but as soon > as you start pressing keys, the load goes maybe to 80% of a CPU core. > This program I run with rtprio 8 xxx. The issue I observe or hear > actually, is that it takes too long until the scheduler grasps that this > program needs it's own CPU core and stops time-sharing the program. When > I however use cpuset -l xxx rtprio 8 yyy everything is good, and the > program outputs realtime audio in-time. > > Or is this perhaps a CPU frequency stepping issue? > > Any advice on where to look?
There were some bug fixes earlier this year to address problems where high-priority threads were not getting scheduled quickly enough. If you're using an old kernel, they might improve things: https://cgit.freebsd.org/src/commit/?id=0927ff78147b4d00a75054bbad299946208e1e91 https://cgit.freebsd.org/src/commit/?id=6d3f74a14a83b867c273c6be2599da182a9b9ec7 https://cgit.freebsd.org/src/commit/?id=03f868b163ad46d6f7cb03dc46fb83ca01fb8f69 https://cgit.freebsd.org/src/commit/?id=a889a65ba36985dfb31111ac1607be35ca2b2c8c Otherwise, you might try using tools/sched/schedgraph.d and schedgraph.py to visualize what's going on. schedgraph.d logs all scheduler events of interest and schedgraph.py presents a row for each CPU and thread in the system, making it easier to see why threads are waiting on runqueues.
