Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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...

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

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.

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

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
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
Thanks for the explanation about realtime priorities. However I found that echo 0 > /proc/sys/kernel/sched_autogroup_enabled also did the trick (from…) – Willem Apr 20 '13 at 9:59

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