Re: Linux 2.6 Scheduling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks Scott,
 
I will come up with more questions later.
 
Nobin

 
On 6/19/08, Scott Lovenberg <scott.lovenberg@xxxxxxxxx> wrote:
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! :)


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux