Periodic tasks are not nice

Norman Gray norman.gray at glasgow.ac.uk
Mon Jun 14 22:37:08 UTC 2021


Ronald, hello.

On 14 Jun 2021, at 21:49, Ronald F. Guilmette wrote:

> But on the other hand, if a given process is starved of CPU, then it
> will naturally be less able to suck up all of the available actuator
> movements of the spinning rust disks that I am still cheap enough to
> own, yes?

For me, the aha! here is that nice doesn't artificially starve a process 
of CPU, it merely puts it to the back of the queue when the kernel is 
scheduling it.  That means that _if_ there is a shortage of CPU, then 
the process will not be given a turn on the CPU very often (depending on 
the value of the niceness).

If, on the other hand, there are two (single-threaded) processes 
running, A and B, with only the second one niced, and two CPUs, then 
there is _no_ shortage of CPU.  Thus B can be given the second CPU to 
play with, without disrupting A.  Both CPUs will be fully utilised, and 
the CPU scheduling queue will be empty most of the time.

If A were multi-threaded, then it would be possible for the kernel to 
schedule it on both CPUs.  In that case, the kernel would do so more 
often for A than for B, and B would be starved.

Returning to the case where A is single threaded, consider the case 
where B, again making full use of a CPU, is doing something which is 
thrashing the disk.  This time, the kernel will spend more time 
servicing process B and its disk accesses, so A will end up waiting in a 
queue for disk access, and so be slowed down by B, even though it's B 
that's niced.

(I'm sure no-one will hold back from correcting me if I've misunderstood 
something, or skipped a subtlety).

Best wishes,

Norman


-- 
Norman Gray  :  http://www.astro.gla.ac.uk/users/norman/it/
Research IT Coordinator
SUPA School of Physics and Astronomy, University of Glasgow, UK
Charity number SC004401


More information about the freebsd-questions mailing list