Re: RUNPTY and TIMESLICE in *CLS objects

Hello Sam,

Am 16.12.2021 um 19:08 schrieb Sam_L <lennon_s_j@xxxxxxxxxxx>:

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.

Matches what Michael Catalani wrote.

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.

And now comes the interesting question: How fast is it interrupted? After the internal time slice end (500 ms)?

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.

Yap, this is common understanding. But is it *right*? Because when a batch process is using the CPU and some interactive process wants the CPU *now* (so the session doesn't feel laggy), how fast can the time slice be ended prematurely? Almost surely not 5 seconds wall clock.

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.

Yes, one of the many really outstanding engineering feats: Don't waste CPU cycles with waiting. Just try to run the next task. Somewhat oversimplified, though. ;-)

:wq! PoC