Messages in this thread | | | From | Markus Kuhn (CIP 90) <> | Subject | Re: real time syscall man pages | Date | Sun, 31 Mar 1996 20:54:43 +0200 (MET DST) |
| |
> I need man pages for the system calls 154 - 163: > sched_setparam > sched_getparam > sched_setscheduler > sched_getscheduler > sched_yield > sched_get_priority_max > sched_get_priority_min > sched_rr_get_interval > nanosleep > mremap
> Are these man pages available? If so where?
I have already written one for nanosleep() and will submit it in the next few days to the man page maintainer (Andries Brouwer). I did not yet have the time to write those for sched_*, and I'd be glad if you could write them. I know nothing about mremap(), which is not POSIX.
> If there are no man pages for these system calls I could write them, > provided that someone mails me the relevant information.
> (I have got the book "Programming for the real world POSIX.4" > by Bill O. Gallmeister, O'Reilly & Associates --- but I need to > know if and how the Linux implementation differs from the book.)
Ok, here is some explanation:
Linux has two kinds of priorities: the classic unix priorities which you can influence by nice() and by the interactiveness of the application, and the static POSIX.1b priority, which you can control with the sched_* functions.
For Linux, the static POSIX.1b priorities 0-99 are possible. The classic Linux time sharing scheduler (known under POSIX.1b as SCHED_OTHER) can only run inside static POSIX.1b priority 0 if no higher real-time processes are runnable. The real-time schedulers SCHED_FIFO and SCHED_RR can only run in static POSIX.1b priorities 1-99. The priority level which you can influence with nice() only affects processes running at POSIX.1b priority 0 (i.e., all non-realtime processes). Under Linux, you need root privileges in order to get into a static POSIX.1b priority level higher than 0.
These are the most relevant things, the rest schould be clear from the Gallmeister book, from the IEEE standard, or from the sched.c source code. Contact me if you need more information and please send me the manpages once you have finished them.
Sched_rr_get_interval is not yet implemented, because I am not sure, which value it is supposed to return. It just returns ENOSYS at the moment. In addition, I have some doubts whether SCHED_RR is already doing what it is supposed to do, because if you fork two processes and let them both do the same task with the same priority under SCHED_RR, then they do not finish this task at the same time. Try it yourself with two SCHED_RR processes printing AAAA and BBBB on the console screen! One of them seems to have a slight advantage over the other one. In addition, I have not really understood the SCHED_RR code written by Linus.
It would also be nice if the man pages contained some description about what are the worst case conditions with regard to the time, the highest priority process needs to get reactivated after the interrupt that made this process runnable again (e.g. an incoming serial byte) has been processed. Any scheduler experts who want to comment on this issue? Linus?
Markus
-- Markus Kuhn, Computer Science student -- University of Erlangen, Internet Mail: <mskuhn@cip.informatik.uni-erlangen.de> - Germany WWW Home: <http://wwwcip.informatik.uni-erlangen.de/user/mskuhn>
| |