GNU bug report logs - #11437
nice: tests: please disable on hurd-i386

Previous Next

Package: coreutils;

Reported by: Samuel Thibault <samuel.thibault <at> gnu.org>

Date: Tue, 8 May 2012 18:43:01 UTC

Severity: wishlist

Full log


Message #11 received at 11437 <at> debbugs.gnu.org (full text, mbox):

From: Samuel Thibault <samuel.thibault <at> gnu.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: bug-hurd <at> gnu.org, 11437 <at> debbugs.gnu.org
Subject: Re: bug#11437: coreutils: Please disable misc/nice test on hurd-i386]
Date: Sat, 12 May 2012 17:18:36 +0200
Eric Blake, le Tue 08 May 2012 12:54:08 -0600, a écrit :
> On 05/08/2012 12:39 PM, Samuel Thibault wrote:
> > The misc/nice test currently fails on hurd-i386 because the nice support
> > there is not precise enough: the Mach kernel, which handles scheduling
> > priorities, has only 32 priority levels, and not 40, so conversion is
> > used, but that becomes not precise enough for the misc/nice test.  Apart
> > from that, the nice tool works fine. Could you disable that test on
> > hurd-i386?
> 
> What is the mapping between the kernel's 32 levels and the
> POSIX-mandated minimum of 40 niceness levels (that is, which niceness
> levels are rounded to a neighbor)?  Can we rewrite the test to use just
> niceness levels provided by Hurd?

It's a simple factor 2:

#define MACH_PRIORITY_TO_NICE(prio) (2 * ((prio) - 12))
#define NICE_TO_MACH_PRIORITY(nice) (12 + ((nice) / 2))

> In fact,
> if you could track 64 niceness levels, and just have every pair of
> niceness levels map to the kernel priorities, then you would be
> POSIX-compliant (POSIX doesn't require that niceness level 0 and 1 have
> any difference in scheduling, only that you can have niceness levels
> between 0 and 2*NZERO-1).

Right, but that'd means that libc has to remember all priorities, to
be able to return them, including other processes (it's not only about
nice, but also get/setpriority).

OTOH, we could as well extend mach's priorities to 40 levels and change
the mappping. The only issue with that is that when using a patched libc
(using >32 priority values) with a non-patched kernel (refusing them),
some nice values will be refused by kernel. Maybe we can consider it's
not a problem that people have to upgrade their kernel to fix it.

Samuel




This bug report was last modified 6 years and 327 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.