Subject: bug#11437: coreutils: Please disable misc/nice test on hurd-i386]

From: Samuel Thibault <[email-masked]>
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