Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 31 Mar 2023 18:09:19 -0000 (UTC)
From:      "Peter 'PMc' Much" <pmc@citylink.dinoex.sub.org>
To:        freebsd-hackers@freebsd.org
Subject:   Re: Periodic rant about SCHED_ULE
Message-ID:  <slrnu2e8ef.5bc.pmc@disp.intra.daemon.contact>
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> <CAK7dMtAsBehP2cy6cn31Z%2BSo6T2Q_mpN5ibEmYMNPOkWQHk8FA@mail.gmail.com> <CAK7dMtAHOpq579Hb_Ar3e-VaYZGfawAxBMDoM0Zt0T_=UD5Jgw@mail.gmail.com> <CAGudoHGNRQudBUj-XCNb=AirOgWn%2Bs0mi96v3axK4ZZSSdybZA@mail.gmail.com> <a2740715-bb8f-8c16-04d0-c84e2e6c9622@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2023-03-30, Matthias Andree <mandree@FreeBSD.org> wrote:
> Am 30.03.23 um 20:50 schrieb Mateusz Guzik:
>
>> Anyhow after sending the above e-mail an actual solution hit me: the X
>> server can tell the kernel what processes connect to it over the unix
>> socket, which again very well may be good enough.
>> 
>> In the reports I got I found pulseaudio, this one may need to be
>> patched in a similar manner.
>
> Pulseaudio shouldn't need such stuff since it would either try to go 
> into a real-time scheduling group (which I don't think SCHED_ULE would 
> have), or do a (privileged) renice -11 to have considerable priority 
> over non-privileged stuff. At least on Linux, that is.
>

>From what I get, it seems most people with professional audio are
using JACK, and JACK runs in rtprio by default:

UID  PID PPID  C PRI NI     VSZ     RSS MWCHAN   STAT TT        TIME COMMAND
1100 1404 1403  2 -51  0  153508   71816 sigwait  I<s   -     1:28.97 /usr/local/bin/jackd -r

With the other aspects, I think there are two different
issues. One issue is that compute jobs do not always get
their fair timeshare - this is concerning servers with
batch compute load: I need such tasks to complete within
precalculated time, and that does not always happen now.

The other is about interactivity scoring etc., and that concerns
mainly desktop systems, and I think that is a bit more difficult to
get proper. 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?slrnu2e8ef.5bc.pmc>