Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

This question already has an answer here:

Given a VM with 1 CPU. I run two similar CPU intensive tasks in two terminals:

/usr/bin/nice -n -20 perl -e 'while(1){$a=1+1;}'
/usr/bin/nice -n 19 perl -e 'while(1){$a=1+1;}'

I would expect that when I check with top, 1 process would take all the CPU and the other none (because there is no idle time left). But...

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
18175 root       1 -20 20376 1460 1132 R  49.9  0.1   0:18.36 perl
18176 root      39  19 20376 1460 1132 R  49.9  0.1   0:15.16 perl   

Why is that? I want my process to humbly only use idle CPU cycles :)

Tested on Linux 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

share|improve this question
    
Is that "one CPU with hyperthreading"? In that case the higher prio process cannot consume the other one's CPU time if it's single-threaded (as this computation obviously is). Does pressing I change this top output to nearly 100%? –  Hauke Laging Apr 19 '13 at 19:56
    
It doesn't have ht. However, disabling the autogroup scheduler feature did the trick, see the comment on mdpc's answer. –  Willem Apr 20 '13 at 10:01
add comment

marked as duplicate by sysadmin1138 Apr 20 '13 at 11:06

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1 Answer

There is an "art" used in task scheduling. The standard Linux/Unix scheduling algorithm allows all processes at some point to get CPU. This is done by initially, assigning a process two items: (1) lowest priority in its catagory (as determined from its nice) and (2) a time increment again based on priority cateory. As time goes on the process priority gets incremented, the highest priority process gets CPU time. Also, the process getting CPU is continually redetermined from tick to tick based on highest priority at that time after the recalculation. Once a process gets CPU time, its priority returns again to the lowest priority in its catagory.

You could get what you wanted by using "realtime" priorities, where highest priority class processes gets the CPU and gets to use it until all processes in the priority class are satisified, then processes in the next lower class gets the available time, until either a higher priority process requires the CPU, and so on until the total CPU scheduling increment is used up. A process can relinquish part of the CPU increment, thus causing a reschedule.

Thus you are seeing on using the standard scheduler, your lower priority process still getting CPU time but at a far lower rate.

share|improve this answer
1  
Mostly right, but This is done by initially, assigning a process two items, (1) lowest priority in its catagory (as determined from its nice) and (2) an time increment again based on priority cateory. is not quite right, on linux the value with the lowest se.vruntime is scheduled to run. This is in /proc/<pid>/sched. Niceness alters how vruntime is added to when a task is preempted so as to raise or lower the vruntime actually accumulated whilst the task was running. nice actually changes the weight value in /proc/<pid>/sched –  Matthew Ife Apr 19 '13 at 20:17
1  
Thanks for the explanation about realtime priorities. However I found that echo 0 > /proc/sys/kernel/sched_autogroup_enabled also did the trick (from serverfault.com/questions/405092/…) –  Willem Apr 20 '13 at 9:59
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.