public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Michael Kerrisk" <mtk-manpages@gmx.net>
To: mingo@elte.hu
Cc: linux-kernel@vger.kernel.org, michael.kerrisk@gmx.net, akpm@osdl.org
Subject: Broke nice range for RLIMIT NICE
Date: Thu, 28 Jul 2005 17:04:24 +0200 (MEST)	[thread overview]
Message-ID: <32710.1122563064@www32.gmx.net> (raw)

Hello Ingo,

I'm guessing that it was you that added the RLIMIT_NICE resource 
limit in 2.6.12.  (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).

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?

Cheers,

Michael

-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  Grab the latest
tarball at ftp://ftp.win.tue.nl/pub/linux-local/manpages/
and grep the source files for 'FIXME'.

             reply	other threads:[~2005-07-28 15:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-28 15:04 Michael Kerrisk [this message]
2005-07-28 17:43 ` Broke nice range for RLIMIT NICE Andrew Morton
2005-07-29 11:29   ` [PATCH] MAINTAINERS record -- MAN-PAGES Michael Kerrisk
2005-07-29  6:13 ` Broke nice range for RLIMIT NICE Matt Mackall
2005-07-29  8:38   ` Ingo Molnar
2005-07-29 10:42     ` Michael Kerrisk
2005-07-29 14:50       ` Nix
2005-07-29 15:14         ` Michael Kerrisk
2005-07-29 20:57           ` Nix
2005-07-29 10:40   ` Michael Kerrisk
2005-07-29 20:18   ` Chris Wright
2005-07-29 20:51     ` Chris Wright
2005-07-29 21:02       ` Lee Revell
2005-07-29 21:07         ` Chris Wright
2005-08-15 20:13   ` [PATCH] Fix " Matt Mackall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32710.1122563064@www32.gmx.net \
    --to=mtk-manpages@gmx.net \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.kerrisk@gmx.net \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox