Uncommented description of RLIMIT_NICE that I wrote earlier

This commit is contained in:
Michael Kerrisk 2005-09-19 14:57:05 +00:00
parent 363f747ccd
commit a23bf8a396
1 changed files with 18 additions and 16 deletions

View File

@ -244,23 +244,25 @@ The first addend in the formula, which includes
(4 bytes on Linux/x86), ensures that the user cannot
create an unlimited number of zero-length messages (such messages
nevertheless each consume some system memory for bookkeeping overhead).
.\" FIXME the following commented out, since the off-by-one mismatch
.\" between [gs]etpriority() (40..1) and RLIMIT_NICE (39..0) is likely
.\" to be fixed in 2.6.13 -- MTK, 29 Jul 05
.\" In kernel 2.6.12, there was an off-by-one mismatch
.\" between [gs]etpriority() (40..1) and RLIMIT_NICE (39..0);
.\" this was fixed in 2.6.13
.\" see http://marc.theaimsgroup.com/?l=linux-kernel&m=112256338703880&w=2
.\"
.\" .TP
.\" .BR RLIMIT_NICE "(since kernel 2.6.12)"
.\" Specifies a ceiling to which the process nice value can be raised using
.\" .BR setpriority (2)
.\" or
.\" .BR nice (2).
.\" The actual ceiling for the nice value is calculated as
.\" .IR "19\ \-\ rlim_cur" .
.\" (This strangeness occurs because of the differences in user-land
.\" and kernel representations of the nice value, as described in
.\" .BR getpriority (2)).
.\"
.TP
.BR RLIMIT_NICE " (since kernel 2.6.12)"
Specifies a ceiling to which the process nice value can be raised using
.BR setpriority (2)
or
.BR nice (2).
The actual ceiling for the nice value is calculated as
.IR "20\ \-\ rlim_cur" .
(This strangeness occurs because of the differences in user-land
and kernel representations of the nice value, as described in
.BR getpriority (2).
Eventually, glibc might hide things to make the range given to
.BR RLIMIT_NICE
to be the same as
.BR setrlimit (2).)
.\" FIXME (28 Jul 05) -- must check later whether glibc hides this issue
.\" by performing a calculation similar to "unice == 20 - knice"
.\" (like [gs]setpriority()) when dealing with RLIMIT_NICE