3 ms·

> that wasn't really 100% cpu Can you explain?

• wtallis 3y ago
  That's probably referring to the fact that running 'yes' is going to spend virtually all of its time on syscall and context switch overhead, and minimal real work or IO. So conclusions from such a test may not generalize to any kind of realistic workload.
• dekhn 3y ago
  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.