Date: Mon, 14 Jun 2021 23:37:00 +0100 From: Norman Gray <norman.gray@glasgow.ac.uk> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: John Levine <johnl@iecc.com>, <freebsd-questions@freebsd.org> Subject: Re: Periodic tasks are not nice Message-ID: <C04DEBFB-CD03-4B6A-9B25-976435220958@glasgow.ac.uk> In-Reply-To: <3360.1623703751@segfault.tristatelogic.com> References: <3360.1623703751@segfault.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C04DEBFB-CD03-4B6A-9B25-976435220958>