Further reworking of discussion or RLIMIT_NICE and RLIMIT_RTPRIO

This commit is contained in:
Michael Kerrisk 2005-09-20 17:43:58 +00:00
parent 8ba10b3e91
commit cedd678ff7
1 changed files with 8 additions and 15 deletions

View File

@ -59,7 +59,7 @@
.\" 2005-07-13, mtk, documented RLIMIT_MSGQUEUE limit. .\" 2005-07-13, mtk, documented RLIMIT_MSGQUEUE limit.
.\" 2005-07-28, mtk, Added descriptions of RLIMIT_NICE and RLIMIT_RTPRIO .\" 2005-07-28, mtk, Added descriptions of RLIMIT_NICE and RLIMIT_RTPRIO
.\" .\"
.TH GETRLIMIT 2 2005-07-28 "Linux" "Linux Programmer's Manual" .TH GETRLIMIT 2 2005-09-20 "Linux" "Linux Programmer's Manual"
.SH NAME .SH NAME
getrlimit, setrlimit \- get/set resource limits getrlimit, setrlimit \- get/set resource limits
.SH SYNOPSIS .SH SYNOPSIS
@ -246,22 +246,15 @@ create an unlimited number of zero-length messages (such messages
nevertheless each consume some system memory for bookkeeping overhead). nevertheless each consume some system memory for bookkeeping overhead).
.TP .TP
.BR RLIMIT_NICE " (since kernel 2.6.12, but see BUGS below)" .BR RLIMIT_NICE " (since kernel 2.6.12, but see BUGS below)"
Specifies a ceiling to which the process nice value can be raised using Specifies a ceiling to which the process's nice value can be raised using
.BR setpriority (2) .BR setpriority (2)
or or
.BR nice (2). .BR nice (2).
The actual ceiling for the nice value is calculated as The actual ceiling for the nice value is calculated as
.IR "20\ \-\ rlim_cur" . .IR "20\ \-\ rlim_cur" .
(This strangeness occurs because of the differences in user-land (This strangeness occurs because negative numbers cannot be specified
and kernel representations of the nice value, as described in as resource limit values, since they typically have special meanings.
.BR getpriority (2). For example, RLIM_INFINITY typically is the same as \-1.)
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
.TP .TP
.B RLIMIT_NOFILE .B RLIMIT_NOFILE
Specifies a value one greater than the maximum file descriptor number Specifies a value one greater than the maximum file descriptor number
@ -292,8 +285,8 @@ specifying
.\" -- MTK, Jul 05 .\" -- MTK, Jul 05
.TP .TP
.BR RLIMIT_RTPRIO " (Since Linux 2.6.12, but see BUGS)" .BR RLIMIT_RTPRIO " (Since Linux 2.6.12, but see BUGS)"
Specifies a ceiling on the real-time priority that the calling Specifies a ceiling on the real-time priority that may be set for
process may set using this process using
.BR sched_setscheduler (2) .BR sched_setscheduler (2)
and and
.BR sched_setparam (2). .BR sched_setparam (2).
@ -365,7 +358,7 @@ between the priority ranges returned by getpriority(2) and
This had the effect that actual ceiling for the nice value This had the effect that actual ceiling for the nice value
was calculated as was calculated as
.IR "19\ \-\ rlim_cur" . .IR "19\ \-\ rlim_cur" .
This was fixed in kernel 2.6.13 This was fixed in kernel 2.6.13.
.\" see http://marc.theaimsgroup.com/?l=linux-kernel&m=112256338703880&w=2 .\" see http://marc.theaimsgroup.com/?l=linux-kernel&m=112256338703880&w=2
.SH "CONFORMING TO" .SH "CONFORMING TO"
SVr4, 4.3BSD. SVr4, 4.3BSD.