Re: ULE realtime scheduler advice needed

From: Alexander Leidinger <Alexander_at_leidinger.net>
Date: Fri, 18 Nov 2022 08:18:28 UTC
Quoting Hans Petter Selasky <hps@selasky.org> (from Fri, 18 Nov 2022  
05:47:58 +0100):

> 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.

I have something in my mind about ULE not handling idleprio and/or  
rtprio correctly, but I have no pointer to a validation of this.

> Or is this perhaps a CPU frequency stepping issue?

You could play with
rc.conf (/etc/rc.d/power_profile):
performance_cpu_freq="HIGH"
performance_cx_lowest="C3"   # see sysctl hw.cpu.0 | grep cx
economy_cx_lowest="C3"       # see sysctl hw.cpu.0 | grep cx

Your system may provide other Cx possibilities, and ging to a lower  
number (e.g. C1) means less power-saving but faster response from the  
CPU (I do not expect that this is causing the issue you have).

> Any advice on where to look?

Potential sysctl to play with to change "interactivity detection" in ULE:
https://www.mail-archive.com/freebsd-stable@freebsd.org/msg112118.html

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF