Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Nov 2022 14:12:44 -0500
From:      Mark Johnston <markj@freebsd.org>
To:        Hans Petter Selasky <hps@selasky.org>
Cc:        FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: ULE realtime scheduler advice needed
Message-ID:  <Y3vNrPwOrsYRhMzP@nuc>
In-Reply-To: <7ad10a5e-29d6-aaef-25cf-407d65f056cc@selasky.org>
References:  <7ad10a5e-29d6-aaef-25cf-407d65f056cc@selasky.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Y3vNrPwOrsYRhMzP>