Re: Periodic rant about SCHED_ULE

From: Alexander Leidinger <>
Date: Fri, 31 Mar 2023 07:28:53 UTC
Quoting Mateusz Guzik <> (from Thu, 30 Mar 2023  
17:36:54 +0200):

> Right now I'm toying with the idea of either:
> 1. having programs explicitly tell the kernel they are interactive

There is no POSIX interface to do this. I'm not aware of a widespread  
use of private interfaces in other unix-like operating systems to do  
I consider modifying all interactive programs with FreeBSD specific  
code to do so a bad idea.
I consider modifying the X server with FreeBSD specific code to do so  
on behalf of programs using it a bad idea too (what about interactive  
non-X-using programs I start in an xterm or from the vidconsole?).

> 2. adding a scheduler hook to /dev/dsp -- the observation is that if a
> program is producing sound it probably should get some cpu time in a
> timely manner. this would cover audio/video players and web browsers,
> but would not cover other programs (say a pdf reader). it may be it is
> good enough though

What if I don't have an audio device on a system but run interactive  
programs on it? You told it yourself, it favourites a specific class  
of programs. Please think this to the end, you are telling you only  
want to priorize a subset of interactive processes and leave others  
alone. If you are honest to yourself, you need to say this is a hack,  
not a solution.

My suggestion is to first fix the bugs we/you are able to fix (number  
2), and then to measure again with a bigger sample size. Small  
evolution and re-observation instead of a big bang fix of everything  
based upon assumptions of what impact the smaller fixes may have on  
our big population of use cases.

Maybe someone has an idea how to factor out lock contention in the  
mean time, and we can have a look if this improves something for  
someone by providing it as a fix (no matter if gated by a sysctl or  
not) and we can re-measure again.


-- PGP 0x8F31830F9F2772BF  : PGP 0x8F31830F9F2772BF