Re: ULE realtime scheduler advice needed

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.