[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology

Name
Options
Comment
Verification
4chan Pass users can bypass this verification. [Learn More] [Login]
File
  • Please read the Rules and FAQ before posting.
  • You may highlight syntax and preserve whitespace by using [code] tags.

08/21/20New boards added: /vrpg/, /vmg/, /vst/ and /vm/
05/04/17New trial board added: /bant/ - International/Random
10/04/16New board for 4chan Pass users: /vip/ - Very Important Posts
[Hide] [Show All]


[Advertise on 4chan]


File: 1726619967068716.png (478 KB, 839x798)
478 KB
478 KB PNG
previous: >>108565168

#define __NR_sched_setparam            142
#define __NR_sched_getparam 143
#define __NR_sched_setscheduler 144
#define __NR_sched_getscheduler 145
#define __NR_sched_get_priority_max 146
#define __NR_sched_get_priority_min 147
#define __NR_sched_rr_get_interval 148
#define __NR_sched_setattr 314
#define __NR_sched_getattr 315

https://man7.org/linux/man-pages/man7/sched.7.html

tl;dr:
process scheduling!

note that i'm skipping over get/setaffinity, since they're imo distinct enough to warrant their own thread
now *surely* this is a subject on which /g/ has opinions, right? everyone's taken an OS course if they've studied CS, and most all of those at least attempt to force you to play around with different scheduling algorithms (especially the round robin classic). so let's hear what you have to say on the matter!
looking at it now, the sched(7) manpage is actually pretty well-written. i wish i hadn't been scared off by manpages back when i was in university. a lot of times, reading them or the kernel source itself can be more enlightening than any textbook. depends on the subject, though, i guess
personally, i honestly didn't enjoy mucking about with scheduling algorithms. i was never a huge fan of algorithms in general :') but learning about it (and really, more so than just scheduling, the fundamentals of operating systems) was suuuper helpful as a foundation for learning basically everything else i know now
this is maybe a bit outside the normal scope of these threads, but i'll be nice and throw out an especially helpful resource for those of you who are interested in learning more: https://www.youtube.com/@Udacity/courses
don't want to come across as a shill or anything, but it's totally free (it's effectively just a video playlist... dunno why they're organized in this weird way), and some of them are *really* good. if you've enjoyed these threads so far and want to learn more, i'd strongly recommend taking a peek at the playlists available here and checking out some of the relevant ones. obviously the "developing scalable apps with java" course is going to be slightly less useful to you than "advanced operating systems parts 1-4"...

bonus activity: tag urself (me in the top right)

relevant resources:
man man

man syscalls

https://man7.org/linux/man-pages/
https://linux.die.net/man/
https://elixir.bootlin.com/linux/
https://elixir.bootlin.com/musl/
https://elixir.bootlin.com/glibc/
>>
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 (1.96 MB, 1920x1080)
1.96 MB
1.96 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



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.