the yes command, writing to /dev/null, is making IO calls, which interfere with predictable scheduling. If you look at the source code for yes, https://github.

the yes command, writing to /dev/null, is making IO calls, which interfere with predictable scheduling. If you look at the source code for yes, https://github.com/coreutils/coreutils/blob/master/src/yes.c https://github.com/coreutils/coreutils/blob/master/src/yes.c it builds a buffer of output and then writes that in a for loop while (full_write (STDOUT_FILENO, buf, bufused) == bufused) continue; Inside the kernel, /dev/null is handled by doing nothing. So basically when this runs, the majority of the CPU time it consumes is just context switches from process to kernel and back. It consumes 100% of a core on an idle machine, but what you really want for your basic scheduling test is to have a pure CPU hog with no kernel transitions (I've seen variations- increment a register, do some light flops that don't hit memory, or even just a nop loop (which is basically "increment register, branch if less than"). If you get the expected performance on the cpu hog, then you can proceed to the yes hog.