LinuxQuestions.org - 'nice' priority is working backwards!

- Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)

- - 'nice' priority is working backwards! (https://www.linuxquestions.org/questions/linux-software-2/nice-priority-is-working-backwards-256694/)

'nice' priority is working backwards!

I've been playing around with 'nice' for increasing the priority for a script I'm working on. The script uses mplayer and mpeg2enc to encode video; I am running each of them at the same priority (see the tovid discussion for details). 'nice' seems to be working backwards on my machine.

nice is supposed to work so that -20 is the highest priority, and 19 is the lowest priority, according to the nice manual. My Folding@home client is running at nice 19. So, to overpower Folding@home, I should use a "high" priority, like, say, -10. Doing that, 'top' shows this:

Code:

 7971 foldinga  39  19 70920  10m 2112 R 91.5  2.1  2633:13 FahCore_65.exe                                                          

 4870 eric      15  0 60752  43m  31m S  3.3  8.6  1:33.95 firefox-bin

 8058 root      15  0  139m  73m  74m S  2.3 14.5  75:14.37 X

 8078 eric      15  0 13508 7680  10m S  0.3  1.5  4:34.19 gkrellm2                                                                

    1 root      16  0  1364  472 1212 S  0.0  0.1  0:00.11 init

    2 root      34  19    0    0    0 S  0.0  0.0  0:00.00 ksoftirqd/0

    3 root      5 -10    0    0    0 S  0.0  0.0  0:01.44 events/0

    4 root      5 -10    0    0    0 S  0.0  0.0  0:00.00 khelper

And so on... mplayer and mpeg2enc are not even on the list, and when they are, they're using <1% CPU. Estimated encoding time remaining: 267 hours.

Now, trying a "low" priority of 19 (equal to Folding@home), here's what happens:

Code:

 7971 foldinga  39  19 70920  10m 2112 R 53.6  2.1  2634:35 FahCore_65.exe                                                          

16820 eric      35  19 11884 9.8m 2396 R 21.6  1.9  0:01.25 mpeg2enc                                                                

16817 eric      34  19 35020  14m  26m S 13.0  2.9  0:00.97 mplayer                                                                

 8058 root      15  0  139m  73m  74m S  4.0 14.5  75:20.48 X

 4870 eric      15  0 60752  43m  31m S  2.3  8.6  1:39.10 firefox-bin

15530 eric      15  0  3636 2208 2780 S  1.0  0.4  0:00.41 rxvt

16819 eric      15  0  1356  340 1200 S  1.0  0.1  0:00.05 cat

Estimated encoding time remaining: 36 minutes. Now, this is perplexing - Folding@home should have the lowest priority, so it doesn't interfere with other processes (hence, nice 19). But it has the highest priority, so high that it still gets 50-60% of the CPU even when other processes have the same priority.

I have also tried turning off Folding@home. With it gone, encoding uses no more than a total of 50% of my CPU; the rest sits idle. Again, using a lower number causes it to use less CPU, with -20 using practically none. Video encoding is a very CPU-intensive process, and should very easily be using 100% if it is allowed.

Can anyone explain what is going on here? Could it be a kernel bug? (Using Gentoo 2.6.8). I've already installed the latest version of coreutils (which includes nice), but it had no effect.

A likely reason is that Folding@home is a compute bound process (meaning it almost never has to touch the disk, or some i/o device). Whereas mplayer and mpeg2enc are certainly hitting the disk. When they do this they are blocked until they get what they need from disk. While they are blocked Folding@home is fairly likely to run (if you aren't doing much else).

That makes sense; however, it doesn't explain why my priorities are backwards :)

(I apologize for missing that the priority had not changed between runs of nice)

To lower (set to -10) priority you have to have "...appropriate privileges..." (according to the info manual: "info coreutils nice" for me).

Could it be that you must do this as root?

Hope that's more helpful.

Hi,

This how I have understood Linux priority mechanism:
when it's a high priority (so a negative one): the process is often scheduled with a short CPU time.
when it's a low priority: the process is seldom scheduled (compare to a high prio process) with a longer CPU time.
So the question is why higher prio process have a shorter CPU time??? I think that's because these process are supposed to be "real-time" so interrupts must be processed as quick as possible (that's why that's often scheduled) and as it's real time the processing of the process is also supposed to be fast... and for lower priority process that's the opposed... as they are low prio, they are seldom scheduled and also are they are low prio, they can keep the CPU as as soon as a higher prio process will ask for CPU time, it will have it...

Oliv'

Note: sorry if I'm not as clear as I'd like but my english is limited :p

Thanks for the replies. Yeah, I wasn't sure whether a normal user could set a negative priority; the processes show up under 'top' with the given negative priority, but if it's not actually taking effect, then that would explain the low CPU use. And if high-priority items are only given the CPU for a short time, that would also shed light on the matter.

I've just done a little more testing, comparing priority 19 with priority 0; they both consume about the same CPU, and result in the same encoding time. So clearly, the lack of CPU-hogging is unrelated to priority - as ogmoid said, if there is a lot of disk I/O going on (and there is), that could adversely affect the performance.