Red Hat Bugzilla – Bug 85609
nice on demand
Last modified: 2007-04-18 12:51:51 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
Description of problem:
recently i have been spending a fair amount of time renicing processes on my box
to get a balance of performance and usability. i have noticed that this is a
common (and repetitive) practice for those running X since X tends to be piggy
and easily interferes with things that are processor sensitive. it seems that
the RH distros now automatically nice X to run at -10 so as to make the UI
responsive. this, however, causes things like xmms/esd to behave erratically
(i.e. 'skip') whenever basics windowing events occur. i have seen some renice X
back down to 0, while i renice xmms/esd to -11, which got me thinking...
it would be very cool if the kernel ('nicing module'?) were able to read a
file--say /etc/nice.conf--upon execution of a process to determine what value a
process should be spawned at.
this would make it much easier to build a 'nice profile' that would allow
users/admins to ensure that tuned systems stay that way. admins would benefit in
not having to write down this aspect of performance tweaking for later *manual*
application after inevitable reboots (kernel upgrades, failures, etc.) there
also numerous positive implications in limiting user spawned processes.
This is actually a good suggestion - however, it would seem that this kind of
support would be highly intrusive to implement (unless there is a
straightforward approach I've neglected to find out about).
Reading data files from kernel is generally frowned upon.
Which part can't be solved by a setuid wrapper that just
calls nice () and runs the original program?
for starters, the part that persists this information. a wrapper requires
another execuatble mechanism to be maintained. knowing how many of such files
exist (and where) requires yet another mechanism. ensuring that such wrappers
are used realistically requires replacing the original binary with said
mechanisms (users are going to be looking in well known places for them after
all), which wreaks havoc on package updates.
while i can understand the reticence to have the kernel be dependent upon the
file system, it is not unprecedented (remove /tmp) and is typical for disk
operations (fstab, raidtab) and input behavior (inittab).
that said, it may be entirely possible that this is impractical to implement
programmatically. however, i don't think the case can be made that this would
not be useful operationally.
> for starters, the part that persists this information. a wrapper requires
> another execuatble mechanism to be maintained.
OK, a single wrapper reading a configuration file (see /usr/bin/consolehelper)
> knowing how many of such files
> exist (and where) requires yet another mechanism.
Search for symlinks to nicehlper
> ensuring that such wrappers
> are used realistically requires replacing the original binary with said
> mechanisms (users are going to be looking in well known places for them after
> all), which wreaks havoc on package updates.
Real users are not going to be looking for /usr/bin/xmms, but just for
"xmms". I have no idea whether nice ()'ing executables called
with absolute paths from scripts is that much useful.
> while i can understand the reticence to have the kernel be dependent upon the
> file system, it is not unprecedented (remove /tmp) and is typical for disk
> operations (fstab, raidtab) and input behavior (inittab).
The kernel is not dependent on and not using anything of that.
> The kernel is not dependent on and not using anything of that.
cool. delete grub.conf and fstab and reboot your machine (heck, just delete
/tmp) and tell me how well it works. 'up' and *functional* are two different
things: a running kernel on a disfunctional system is a pyrrhic victory at best.
> I have no idea whether nice ()'ing executables called with absolute paths from
scripts is that much useful.
neither am i, but with your proposed solution (wrappers) not doing so leaves you
with 'history' as your only mechanism for being able to reproduce machine state.
operationally i would say that is a little light.
look, i am not trying to create the holy war of kernel development, just trying
to propose something that would have definite operational value. if it is not
programmtically feasible so be it, but forgive me if i don't withdraw the
suggestion based upon 'generally frowned upon' or 'do it from the command line
and remember what you did' commentary.
in addition... this SHOULD not be needed... it SHOULD be right from the start...
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/