sched_rr_get_interval(2)

💖 sched_rr_get_interval(2) 💖

okay bestie, listen up — this is a page from the System Calls Manual, and it's about sched_rr_get_interval, aka "hey kernel, how long does my round-robin slice actually last?" 🎀 It lives in the Standard C library (libc, -lc), so it's basically part of your everyday toolkit fr fr.

---

✨ NAME ✨

sched_rr_get_interval — get the SCHED_RR interval for the named process 👑

---

📚 LIBRARY 📚

Standard C library (libc, -lc) — the standard issue, no extra download needed, we love that for us 🫶

---

🌸 SYNOPSIS 🌸

#include <sched.h>

int sched_rr_get_interval(pid_t pid, struct timespec *tp);

---

🦋 DESCRIPTION 🦋

so what does it actually do? It writes the round-robin time quantum into the timespec(3) structure that tp points at, and that quantum belongs to the process identified by pid. Simple as.

heads up: the process you're asking about should be running under the SCHED_RR scheduling policy. Otherwise, like, why are you even here 💀

And if pid is zero? Cute question. That means the time quantum for the calling process gets written into *tp. Self-care, honestly 💅

---

💫 RETURN VALUE 💫

• On success, sched_rr_get_interval() returns 0. Slay. ✨
• On error, -1 is returned, and errno is set to tell you exactly what went wrong. Not me checking errno immediately 😭

---

💅 ERRORS 💅

Every single one, no skipping:

• EFAULT — problem with copying information to user space. The copy just… did not go through 🙈
• EINVAL — invalid pid. That number is not it.
• ENOSYS — the system call is not yet implemented (this one's only on rather old kernels, like vintage vintage 🧓)
• ESRCH — could not find a process with the ID pid. It's not there bestie, it's simply not there 💀

---

🌈 VERSIONS 🌈

Linux

Linux 3.9 added a whole new mechanism for adjusting (and viewing) the SCHED_RR quantum: the /proc/sys/kernel/sched_rr_timeslice_ms file exposes the quantum as a millisecond value, and its default is 100. And plot twist — writing 0 to this file resets the quantum to the default value. Iconic behavior honestly ✨

---

⭐ STANDARDS ⭐

POSIX.1-2024. Certified, standardized, doing it by the book 📖

---

🕰️ HISTORY 🕰️

POSIX.1-2001. Yes, this has been around a minute.

Linux

so POSIX straight up does not specify any mechanism for controlling the size of the round-robin time quantum. None. Zero. Nada.

Older Linux kernels said "fine, I'll do it myself" and provided a (nonportable — read that again, bestie, nonportable 🚨) method of doing this. The quantum could be controlled by adjusting the process's nice value (see setpriority(2)). Here's the tea:

• assigning a negative (i.e., high) nice value results in a longer quantum
• assigning a positive (i.e., low) nice value results in a shorter quantum

The default quantum is 0.1 seconds. And the degree to which changing the nice value affects the quantum has varied somewhat across kernel versions — so it was a bit of a wildcard 🎲

This method of adjusting the quantum was removed starting with Linux 2.6.24. Gone. Retired. We don't do that anymore 🪦

---

📝 NOTES 📝

POSIX systems on which sched_rr_get_interval() is available define _POSIX_PRIORITY_SCHEDULING in <unistd.h>. that's the little signal check you can do so you're not out here calling functions that don't exist 💖

---

👀 SEE ALSO 👀

• timespec(3)
• sched(7)

---

and that's the whole page, bestie!! you understood all of it, no cap 🫶 This one's from Linux man-pages 6.20, dated 2026-02-08, and it's still sched_rr_get_interval(2). Go get those time quantums, main character 💅👑✨