it shouldn't be that way... it should be 0 + PORTAGE_NICENESS. here's a patch against current /usr/lib/portage/emerge (2.0.50-r1): ----------------cut------------------- --- emerge.orig 2004-02-28 09:57:03.000000000 +0200 +++ emerge 2004-03-13 10:54:44.558976504 +0200 @@ -60,7 +60,9 @@ if portage.settings.has_key("PORTAGE_NICENESS"): try: - os.nice(int(portage.settings["PORTAGE_NICENESS"])) + n = os.nice(0) + niceness = int(portage.settings["PORTAGE_NICENESS"]) + os.nice( (n < 0 and niceness + -n or niceness - n) ) except Exception,e: print "!!! Failed to change nice value to '"+str(portage.settings["PORTAGE_NICENESS"])+"'" print "!!!",e ----------------cut------------------- nice bash/X to say -15 then run PORTAGE_NICENESS=5 emerge xfree and watch top, emerge process will be running as -10. it should be running as 5! ---excuse my english, i'm sure your arabic ain't that good either :)--- peace
This is a correct behavior, the PORTAGE_NICENESS is just an offset, not an absolute value...
IMHO it should be absolute, i for one (whichi didnt read the exact docs about it :p) expected it was absolute. i'm sure alot of people thought the same. atleast give us 2 values, PORTAGE_NICENESS and PORTAGE_NICENESS_ABSOLUTE. peace
i agree with the current system ... and all the docs reflect this PORTAGE_NICENESS = [number] The value of this variable will be added to the current nice level that emerge is running at. In other words, this will not set the nice level, it will increment it. For more information about nice levels and what are acceptable ranges, see nice(1). # PORTAGE_NICENESS provides a default increment to emerge's niceness level. # Note: This is an increment. Running emerge in a niced environment will # reduce it further. Default is unset.
Created attachment 28260 [details, diff] updated patch to use FEATURES=absnice if FEATURES=absnice is set it'll use absolote nice, if not it'll use the default nice method.
IMHO, implementing such a feature would confuse ppl and the nice ppl on #gentoo that help users. Not to mention the pressure I would receive to change the documentation :p
agreed, i dont think the system needs to be changed at all
it doesnt need to be changed, its a new feature. what you dont know, "should't" hurt you...
It's not immediately that, but introducing new features that change default behaviour in such a way that it's hardly an improvement is more troublesome than else. It's like you're rewriting something that works and behaves the same way, only because you want a different input method. To overkill my explanation, you might say that you want to have PORTACGE_NICECESS accept hex values so you add accepthex as a portage feature... It's not like this is a fix for something that is broken, or a patch to introduce a feature that was non-existant before.
Overly complicated for limited cases. If you're not root, you can't do this.
*** Bug 132739 has been marked as a duplicate of this bug. ***
Well, my bug got marked as a dupe of this one. I understand that it's intended to be environmental niceness + PORTAGE_NICENESS. That's fine. The problem is that portage, when updating itself, restarts inside it's own environment, thus doubling it's own niceness. There is no user control over it at that point. I can set whatever environment I want to start with, but partway through a world update, portage will nice itself down to 19 (rather than 10) resulting in the updating taking forever, since it's now fighting with things like BOINC for resources.
