Periodic tasks are not nice
norman.gray at glasgow.ac.uk
Mon Jun 14 22:37:08 UTC 2021
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
(I'm sure no-one will hold back from correcting me if I've misunderstood
something, or skipped a subtlety).
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