Here's my simplistic take, FWIW.
Time slice is the maximum length of time that a process can monopolize
the CPU. Once that time elapses the process is suspended and the CPU
given to another task at the same run priority, or if no other process
at the same run priority is waiting for the CPU, then to the first
process waiting at the next lower run priority.
Now if a process at a higher run priority wants the CPU (perhaps it was
waiting for an IO to complete and the IO has completed) then the lower
run priority process is interrupted before its time slice has expired.
So an interactive process, which runs at a higher priority, generally
does little CPU work before it gives up the CPU voluntarily because it
is waiting for a non-CPU activity to complete, so it has less
involuntary switching because the time slice has expired. Thus it has a
shorter time slice.
Batch, on the other hand, tends to need more CPU and gets a longer time
slice, but runs at a lower priority.
A process does not have to get to the end of it's time slice before it
is forced to give up the CPU. Requesting an IO, for example, voluntarily
surrenders the CPU.
This is almost certainly a simplified explanation of what happens.
(Run priority goes from 1 as the highest to 99 as the lowest. Normally
interactive is 20, the console is 10, and batch is somewhere 50+.
Nothing should ever run a 10, except the console.)
Sam
On 12/16/2021 11:22 AM, Patrik Schindler wrote:
Hello,
I've read again and again through the Work Management manual but I can't make sense with my Linux background about those attributes.
midrange.com
