Re: Broke nice range for RLIMIT NICE

Matt Mackall
2005-07-29T06:13:34Z

On Thu, Jul 28, 2005 at 05:04:24PM +0200, Michael Kerrisk wrote:
> Hello Ingo,
>
> I'm guessing that it was you that added the RLIMIT_NICE resource
> limit in 2.6.12.

The original patch was from Chris Wright, but I did most of the
cheerleading for it.

> (A passing note to all kernel developers: when
> making changes that affect userland-kernel interfaces, please
> send me a man-pages patch, or at least a notification of the
> change, so that some information makes its way into the manual
> pages).

You might want to make an effort to make yourself more visible around
here. Most of us have no idea that anyone's actually trying to
maintain the manpages or who that might be.

> I started documenting RLIMIT_NICE and then noticed an
> inconsistency between the use of this limit and the nice
> value as manipulated by [sg]etpriority().
>
> This is the documentation I've drafted for RLIMIT_NICE
> in getrlimit.2:
>
> RLIMIT_NICE(since kernel 2.6.12)
> Specifies a ceiling to which the process nice
> value can be raised using setpriority(2) or
> nice(2). The actual ceiling for the nice value is
> calculated as 19 - rlim_cur.
> ^^^^^^^^^^^^^
>
> And recently I've redrafted the discussion of the nice value
> in getpriority.2 and it now reads:
>
> Since kernel 1.3.43 Linux has the range -20..19.
> Within the kernel, nice values are actually repre-
> sented using the corresponding range 40..1 (since
> negative numbers are error codes) and these are the
> values employed by the setpriority and getpriority
> system calls. The glibc wrapper functions for
> these system calls handle the translations between
> the user-land and kernel representations of the
> nice value according to the formula
> user_nice = 20 - kernel_nice.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> In other words, there is an off-by-one mismatch between
> these two interfaces: RLIMIT_NICE is expecting to deal
> with values in the range 39..0, while [gs]etpriority()
> works with the range 40..1.
>
> I suppose that glibc could paper over the cracks here in
> a wrapper for getrlimit(), but it seems more sensible
> to make RLIMIT_NICE consistent with [gs]etpriority() --
> i.e., change the RLIMIT_NICE interface in 2.6.13 before it
> sees wide use in userland. What do you think?

Well, it's easy enough to do, but some thought has to be given to the
corner cases. Specifically, does this do the right thing when the
rlimit is set to zero? I think it does, as the nice range is nicely
bound here:

nice = PRIO_TO_NICE(current->static_prio) + increment;
if (nice < -20)
nice = -20;
if (nice > 19)
nice = 19;

if (increment < 0 && !can_nice(current, nice))
return -EPERM;

And we allow task to do negative increment. Chris?

The other downside is, this obviously changes any existing configs
actually using this by one nice level..

Index: l/kernel/sched.c
===================================================================
--- l.orig/kernel/sched.c 2005-06-22 17:55:14.000000000 -0700
+++ l/kernel/sched.c 2005-07-28 22:55:54.000000000 -0700
@@ -3231,8 +3231,8 @@ EXPORT_SYMBOL(set_user_nice);
*/
int can_nice(const task_t *p, const int nice)
{
- /* convert nice value [19,-20] to rlimit style value [0,39] */
- int nice_rlim = 19 - nice;
+ /* convert nice value [19,-20] to rlimit style value [1,40] */
+ int nice_rlim = 20 - nice;
return (nice_rlim <= p->signal->rlim[RLIMIT_NICE].rlim_cur ||
capable(CAP_SYS_NICE));
}

--
Mathematics is the supreme nostalgia of our time.