Anonymous
syscall of the day: get/setpri(...) 04/09/26(Thu)08:12:27 No.108565168 previous: >>108557703
#define __NR_getpriority 140
#define __NR_setpriority 141
https://man7.org/linux/man-pages/man2/setpriority.2.html
tl;dr:
manage your process's scheduling priority
was conflicted about if i should merge tomorrow's syscalls into this one, but i figured i would keep these separate and do all of the sched_* ones at once
you'll probably want to see also https://man7.org/linux/man-pages/man2/nice.2.html and https://man7.org/linux/man-pages/man7/sched.7.html
nice values are just... bizarre
The range of the nice value varies across UNIX systems. On modern
Linux, the range is -20 (high priority) to +19 (low priority). On
some other systems, the range is -20..20. Very early Linux
kernels (before Linux 2.0) had the range -infinity..15.
i'm sure there's some sort of logic to it, and i could certainly look it up, but maybe someone else already knows and would like to share? let's get some audience participation going!
of interest (to me, at least) is:
C library/kernel differences
The getpriority system call returns nice values translated to the
range 40..1, since a negative return value would be interpreted as
an error. The glibc wrapper function for getpriority() translates
the value back according to the formula unice = 20 - knice (thus,
the 40..1 range returned by the kernel corresponds to the range
-20..19 as seen by user space).
so why even have them be negative in the first place...? goodness!
tomorrow i will probably try to jump start some scheduling algorithm discussion in the thread, but feel free to share your thoughts now, if you have any
the only other thing that really stands out to me today is probably the bugs section:
According to POSIX, the nice value is a per-process setting.
However, under the current Linux/NPTL implementation of POSIX
threads, the nice value is a per-thread attribute: different
threads in the same process can have different nice values.
Portable applications should avoid relying on the Linux behavior,
which may be made standards conformant in the future.
i do think a per-thread implementation is the sane choice, though
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/
