Re: ULE realtime scheduler advice needed
- Reply: Hans Petter Selasky : "Re: ULE realtime scheduler advice needed"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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