Bug 85609
| Summary: | nice on demand | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | bill parducci <bill> |
| Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
| Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | CC: | michael, mitr |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-09-30 15:40:35 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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) would fit? > 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 persists. 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/ |
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.