Re: Periodic rant about SCHED_ULE

On 3/31/23, Alexander Leidinger <Alexander@leidinger.net> wrote:
> Quoting Mateusz Guzik <mjguzik@gmail.com> (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
> this.
> 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?).
>

Of course there are corner cases like that. I'm all ears for a
solution which does not have any.

I once more stress how the current code fundamentally fails to asses
real programs, mpv being an example -- the thread doing video output
was considered least important.

The  current method of "was off cpu there is interactive" literally
does *NOT* work.

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

if they are using X (or wayland), they are marked as such

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

You must have missed the part where I wrote:
> I don't see a clean solution.

Anyhow, if you can show me a real case of an interactive program you
are running in a terminal, which does not use X nor produce sound
*and* suffers from interactivity issues, I'm going to look into it
closer. Do you expect vim to suffer video tearing?

Anyhow even for such a contrived case one can try genuinely devise something.

Did I mention the *current* method actively shafts real interactive programs?

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

An almost bare-minimum fix immediately makes the interactive scoring
issues worse, as I tried to explain. This can be damage-controlled in
a reasonably easy manner and it may be the result will be tolerable
enough for the foreseeable future.

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

No idea is needed. Just not have going-off-cpu-because-of-kernel uses
have the same flag as going-off-cpu-intentionally.

Even then this is not worth pursuing as the fundamental method
involving this is bogus.

-- 
Mateusz Guzik <mjguzik gmail.com>