When I start two CPU-eating processes with different nice-level, e.g.

Process 1:

nice -19 sh -c 'while true; do :; done'

Process 2:

sh -c 'while :; do true; done'

(I changed the order of : and true just to tell the processes apart in outputs of ps or top),

the nice-level seems to be ignored and both use the same amount of CPU.

The output of top is like

 8187 <user>    39  19   21.9m   3.6m 45.8  0.0   0:20.62 R sh -c while true; do :; done
 8188 <user>    20   0   21.9m   3.5m 45.6  0.0   0:20.23 R sh -c while :; do true; done

(of course, the %CPU-values vary slightly from sample to sample, but in average they seem to equal).

top shows that both processes run with different nice values, but still they seem to get same amount of CPU time.

Both commands were run by the same user from different terminals (both are login shells).

If they are run from the same terminal, they behave as expected: The nicer process makes way for the not-so-nice one.

What is the reason? How to make nice work globally on the whole machine?

It was different on that very machine some time before, where nice-values seemed to be honoured.

It is a single processor/ single core machine.

For information:

  • Kernel: Version 4.4.5 (Arch Linux stock kernel); uname -r: 4.4.5-1-ARCH,
  • /proc/cpuinfo is:

    processor       : 0
    vendor_id       : GenuineIntel
    cpu family      : 6
    model           : 23
    model name      : Intel(R) Core(TM)2 Solo CPU    U3500  @ 1.40GHz
    stepping        : 10
    microcode       : 0xa0c
    cpu MHz         : 1400.000
    cache size      : 3072 KB
    physical id     : 0
    siblings        : 1
    core id         : 0
    cpu cores       : 1
    apicid          : 0
    initial apicid  : 0
    fpu             : yes
    fpu_exception   : yes
    cpuid level     : 13
    wp              : yes
    flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm tpr_shadow vnmi flexpriority
    bugs            :
    bogomips        : 2794.46
    clflush size    : 64
    cache_alignment : 64
    address sizes   : 36 bits physical, 48 bits virtual
    power management:
  • Can you post your linux kernel version? uname -a – chaos Apr 19 '16 at 11:40
  • There is a distinction between %CPU and CPU time. Did you start the processes at (almost) the same time? The process with PID 2246 had a lot more (in processorland :-)) CPU time compared to process with PID 3861. – Lambert Apr 19 '16 at 12:44
  • Is your system heavy loaded or only lightly loaded? – fpmurphy Apr 19 '16 at 12:52
  • 1
    This would be expected because of systemd/cgroup stuff if the commands were started from different users login sessions. So maybe check systemd-cgls? It sounds like you're running them in different terminals - does it still happen if you run them both in the background (i.e. add & at the end) on the same terminal? – sourcejedi Apr 19 '16 at 14:14
  • 1
    @sourcejedi: I did run them from different terminals, both as the same user. systemd-cgls is not available, I do not use systemd (I use openrc). I never dealt with cgroups. Starting from the same terminal: Runs as expected. How to restore "old" behaviour without having to dig into cgroups? (Maybe how to deactivate cgroups by default?) – Golar Ramblar Apr 19 '16 at 14:45

Ah, it's not the systemd-logind feature where each user gets it's own cgroup. I think the change responsible here is older; they're just confusingly similar. (I searched "process group fair scheduling", thinking it might be something based on unix's "process groups" that I never really understand). Wikipedia:

The Linux kernel received a patch for CFS in November 2010 for the 2.6.38 kernel that has made the scheduler fairer for use on desktops and workstations.

When a task calls __proc_set_tty(), the process wide reference to the default group is dropped, a new task group is created, and the process is moved into the new task group. Children thereafter inherit this task group, and increase its refcount. On exit, a reference to the current task group is dropped when the last reference to each signal struct is dropped. The task group is destroyed when the last signal struct referencing it is freed. At runqueue selection time, IFF a task has no cgroup assignment, its current autogroup is used.

The feature is enabled from boot by default if CONFIG_SCHED_AUTOGROUP is selected, but can be disabled via the boot option noautogroup, and can be also be turned on/off on the fly [via /proc/sys/kernel/sched_autogroup_enabled: Writing 0 there disables it for newly created tasks, writing 1 enables it.]

The primary issues solved by this are for multi-core as well as multi-cpu (SMP) systems experiencing increased interactive response times while performing other tasks that use many threads in those tasks. A simple explanation is that one will be able to still watch a video, read email and perform other typical desktop activities without glitches or choppiness while compiling the Linux kernel or a similar process such as encoding video. However, there are objections to this statement.

  • 1
    On a running system, autogrouping it can be controlled via /proc/sys/kernel/sched_autogroup_enabled: Writing 0 there disables it for newly created tasks, writing 1 enables it. lwn.net/Articles/416641 was helpful! – Golar Ramblar Apr 20 '16 at 9:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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