Date: Fri, 31 Mar 2023 20:18:57 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: Alexander Leidinger <Alexander@leidinger.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Periodic rant about SCHED_ULE Message-ID: <CAGudoHF1fMd2-HjohXUibqc1wBmHMgTjqzCRY9sd3N3N07ahJg@mail.gmail.com> In-Reply-To: <20230331092853.Horde.OjdeEhUbQnY_fAcTedXJHY5@webmail.leidinger.net> References: <a401e51a-250a-64a0-15cb-ff79bcefbf94@m5p.com> <8173cc7e-e934-dd5c-312a-1dfa886941aa@FreeBSD.org> <8cfdb951-9b1f-ecd3-2291-7a528e1b042c@m5p.com> <c3f5f667-ba0b-c40c-b8a6-19d1c9c63c5f@FreeBSD.org> <ZBtRJhNHluj5Nzyk@troutmask.apl.washington.edu> <CAGudoHEj%2BkoaYhkjzDE5KX9OsCno=X5M_E3z9uwg6Pg7dtqTsA@mail.gmail.com> <CAGudoHHxTT-Cn11zcFB3ZwF76UcRUv=QS28RLgzd=hVehTy0Kg@mail.gmail.com> <CAGudoHGoh30O-3O0jjwevDvP43-ykUt6JUDiwRNW918VZfybhA@mail.gmail.com> <CAGudoHEWfy61XSMhXdYOrKWVotuC0Kc6NSWiaaZCy6aQhbvXoQ@mail.gmail.com> <CAGudoHFPqz_LtsVNnz4P2gyKXz5Z8hU%2Bv6QYGizm4%2BDtZRn8Yg@mail.gmail.com> <CAGudoHGzBjXjXZFs%2BqZJUS-M6VeX5=LB2ifRLP7hFBZXPvqP7g@mail.gmail.com> <20230331092853.Horde.OjdeEhUbQnY_fAcTedXJHY5@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGudoHF1fMd2-HjohXUibqc1wBmHMgTjqzCRY9sd3N3N07ahJg>