Thanks Scott, I will come up with more questions later.
Nobin On 6/19/08, Scott Lovenberg <[EMAIL PROTECTED]> 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! :) >
