Nobin Mathew wrote:
Hi Friends,
I am trying to learn Linux Kernel Internals, and I am going through
Robert Love's Book Linux Kernel Development. I have a doubt regarding
Linux process scheduling.
In the example given in the book, text editor and video encoder have
different priorities.
Text Editor has higher priority and large time slice.
Video Encoder has smaller priority and smaller time slice.
Since Video Encoder is processor intensive it will exhaust it's time
slice very early.
So consider a system which runs only these two applications.
If Video Encoder exhausts it timeslice it will be moved to expired
process queue.
But Text Editor is still running (May be sleeping in a wait
queue) because of its large time slice, that means processor is not
utilized properly.
Is this correct, or Will the kernel do a re-schedule if there no
runnable process.
P.S. : I am not sub-cribed to this list, Please CC me also.
Thanks
Nobin Mathew
You are correct, an I/O blocked process will be put to sleep when it has
nothing to do. When the video encoder exhausts its quantum and the
editor cannot do anything,
the video encoder will be put back on the run queue and both it and the
text editor will be awarded "interactivity credits" (or something to
that effect, I haven't looked at
sched.c since winter ;) ) which will mean that the text editor will be
granted priority (dynamic priority) when you press a key. In other
words, the key press will interrupt
the CPU hogging abruptly. Also, every time that the encoder uses all
its quantum, it will get less of it on the next round until it hits the
lowest possible time slice (100 ms,
IIRC, depending on kernel version) while the text editor will get more
of it each round for not using all of its quantum. Likewise, the text
editor will hit an upper limit (800
ms?) at which it will not gain a larger quantum. A neat experiment is
to skew the numbers in sched.c so that the smallest time slices are very
small, the largest are very big,
and the interactivity credits have many levels (you have to change a
divisor over the 40 possible priority levels, once again, IIRC). Then
start up a CPU hog and top at the
same time and watch what happens to the CPU hog in contrast to top
(which is almost always sleeping), then hold down a key and watch them
equal out again. Really
cool stuff! ;)
I hope this answers your question, I'm somewhat tired and probably not
making as much sense as I would like to. Please follow up with any
questions that I didn't
address. Also, if I'm mistaken about any of the semantics of the
scheduler, will someone please correct me! :)
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
