Hot take: scheduling is a lot less important than writing code that doesn't constantly run into memory stalls. You can assign 100% of your CPU to shitty code and still yield worse results than a thread that runs 1% of the time, but doesn't constantly have to wait for memory.

>>108573186
not agreeing or disagreeing, but what makes you believe that?

>>108573422
Because the kernel is not going to re-schedule a thread that's stalling for memory, because mode switching is more expensive than simply waiting it out - and context switching (i.e. switching to a thread of another process altogether) is about a thousand times more expensive than mode switching.
That's the entire rational behind hyper-threading - that you have hardware support for switching threads of the same process without having to tap into the kernel.

bampu

are all the algos deterministic? meaning for given scheduling parameters and a list of processes with priorities do we for sure know what's the next one

>>108573760
given a snapshot you can say for certain which process is going to run next, yes, but prios get in- and decreased depending on factors such as voluntary relinquishment

in an ideal world, we wouldn't need preemptive scheduling at all. as far as I can tell, I only need realtime scheduling for sound.

>>108574169
preemptive scheduling is used for much more than just realtime, THOUGH.
Any OS in normal interactive use should use preemption. I'm still waiting for the day when the GUI stack is coherent enough to give the currently moused over window extra priority... something Windows has has since the 90s...

In any case, even beyond UI OSes, I'm very much in favour of my car's break preempting the blinker or radio or whatever

>>108575570
you can write your own userspace scheduler believe it or not.

https://github.com/sched-ext/scx

really I'd probably just do 3 first come, first server queues with work stealing and then defer to userspace to let them manager their own interactive bs.

>>108575570
>currently moused over window extra priority
pretty sure the current heuristics will always favor interactivity over full load.

>>108572928
Thanks ChatGPT

>>108572928
I'm sure there's some gold in there, but hundreds of short 2min videos is very much opposite the way I usually learn about thing, so I don't think that channel's for me...

I study with an emphasis on embedded, and schedulers can get very important there. eg I had to mathematically prove certain characteristics of certain algos; they deterministically meet hard deadlines, the maximum delay of soft/firm deadline X is period of X + some other derived value etc.

I'll have a read of sched(7), then;)

and I don't really get picrel, but probably top middle or bottom left

>>108575654
I didn't know. Still, I wouldn't want to replace the kernel's scheduler, just give a slight nudge to process(trees) I deem important, beyond just nice

>>108575673
>AMD has proposed an experimental patch set which enables userspace to provide hints to the scheduler via "Userspace Hinting". The approach adds a prctl() API which allows callers to set a numerical "hint" value on a struct task_struct.
heh, that's precisely what I was referring to. Now to get rid of the >optional part

>>108575732
Are you sure you're not in search of a realtime kernel?

>>108575654
Yeah, for userspace threads. You're better off with a state machine; at least you're not going to have to fuck around with superfluous stack state.

>>108576014
yea, I'm not in search of any kernel, Linux works fine for my desktop
>>108575673
they hype it up quite a bit. changing the scheduler simply by running a userspace binary, not even a module, seems a little icky to me. but regarding actual technical merit, I wonder about the constant overhead this incurs. The kernel's scheduler having to descend the entire staircase from interior kernel to normal userspace binary + libraries surely evicts plenty of cache. But they wouldn't have poured so much energy into the entire thing if it weren't worth it in their use cases

>>108576194
>Linux works fine for my desktop
Realtime-requirements would suggest otherwise.

>>108576124
elaborate please, I don't understand. What's a fully userspace thread?

>>108575732
yeah, i have no idea why they structured it like that. honestly each playlist could be a single video with "chapters"
maybe that feature didn't exist on youtube back when these were getting created, and they wanted a way to easily seek to different sections of the content?
with regard to this thread, though, if you for example started watching from here
https://www.youtube.com/watch?v=jUMUTh9T14k&list=PLAwxTw4SYaPm4vV1XbFV93ZuT2saSq1hO&index=69 through the next fifteen or so videos, you (as in, someone reading this thread - not necessarily you specifically) might get a lot out of it. breaks up scheduling concepts into nice, easily digestible chunks

>>108576385
Mate, just ask google.

>>108572928
I used sched_setscheduler SCHED_FIFO for something at work recently and it didn't make a difference for something really timing sensitive. Was kinda disappointed desu.

>>108578079
what was the use case, if you're able to share?

>>108578245
I'll keep it vague to avoid doxxing myself. I was trying to send a sequence of UDP packets at a very high datarate with very precise spacing, and the jitter was so bad it didn't work.

>>108578385
you might be better off approaching it with synchronization primitives vs via scheduling

>>108578448
The per-packet spacing requirement was a bit over 10us, and any gaps would ruin it. The thread cannot pause at all for that to work, which I think may not be even possible on Linux. You'd certainly need to adjust the scheduler, and I don't see how "synchronization primitives" (you mean futexes?) would help here.

File: 1775756038576724.png (2 MB)

2 MB PNG

nice 19

>>108578641
eepy

>>108576194
>changing the scheduler simply by running a userspace binary, not even a module, seems a little icky to me
https://lpc.events/event/19/contributions/2099/attachments/1875/4020/lpc-2025-lavd-meta.pdf
Meta are using it in production is all you need to know about it. I don't like the company but if they use it at scale and were willing to share to the public they did that, they've done most of the hard work to validate its merits. Of course, server vs desktop does have its differences but I don't think those differences matter from a scheduling front unless you have latency concerns the slides handwave.

>>108578695
>Meta are
shut up Euro

>>108578711
I'm not, was a genuine mistake but whatever, that doesn't mean it's not valid. Even Google has started bundling it as part of Chromium OS.for ChromeOS and is using it most likely for that to be the case
https://chromium.googlesource.com/chromiumos/third_party/scx/+/refs/heads/firmware-R130-16032.B/services/

>>108572928
kys spammer

bampu

>>108578564
I hope you complained at the manufacturer and told them they're a bunch of incompetent clowns.

>>108580385
lol...

i'll do one final bump for this thread

>>108576374
nah, the rt stuff is for work