bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

nice again


From: Marcus Brinkmann
Subject: nice again
Date: Sat, 17 Aug 2002 17:19:32 +0200
User-agent: Mutt/1.4i

Hi,

the shellutils package now has a test suite for nice, and that fails on the
Hurd.  Our nice is not only broken (lowering priority is not supported
because we don't lower the max priority of existing threads), but even if we
would fix that I suspect we would still have problems with mapping 40 values
to 32 (a setpriority followed by a getpriority would show the wrong, rounded
value).  This is very ugly.

There is a way out of this, the question is how much compatibility we want.
As discussed three years ago (Debian bug report#44039), we need to do the
following things (high priority means lower priority values):

if task_priority fails, we need to call it agian with the old value, because
not all threads could be changed, and that in our model usually means
complete failure (as new threads also won't be created with smaller than
thread->max_priority, eg with higher priority than that).

The max priority of all threads needs to be set to a lower value if
priority should be higher, _before_ we can call task_priority to actually
set the priority of the existing and future threads.  This requires the
processor set port (root privileges) so maybe we should leave this to
proc, and add a new RPC to proc for this.  But we could also do it in glibc:
If task_priority fails, and we are root, stop all threads but the current
one, change max priority of all threads, resume all threads, and then go on.

Alternatively, all of this work could be done by a new Mach RPC,
task_max_priority, but this is logically inconsquent because of the
processor set ports... maybe it can take the host control port instead.

For the mapping of nice values:  If a program changes its own priority, we
could store the requested priority value somewhere, and return that instead
of the rounded value if the rounded priority value maintained by the kernel
didn't change.  That's an ugly hack.  Alternatively, we could change the
Mach kernel, but I am afraid that this is a bit intrusive to the scheduler.

Ugly, ugly.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]