scheduler policy

scheduler policy

[shreenivasa H V]

Hi,

In process scheduling, when an epoch ends because of the current process
completing its time quantum (and all the runnable ones having finished their
respective quantums), at the start of the new epoch, will the current running
process retain the cpu (assuming all the runnable ones are of the same
priority)?

Can anyone give some pointers as to where I can find detailed info for linux
process scheduling.

thanks,
shreeni.

Re: scheduler policy

[Mike Kravetz]

On Thu, Sep 13, 2001 at 09:27:56PM -0500, shreenivasa H V wrote:
> Hi,
> 
> In process scheduling, when an epoch ends because of the current process
> completing its time quantum (and all the runnable ones having finished their
> respective quantums), at the start of the new epoch, will the current running
> process retain the cpu (assuming all the runnable ones are of the same
> priority)?

Short answer, for UP kernels yes.

If all the tasks on the runqueue have the same priority (nice value),
then they will all (almost) have the same goodness value at the start
of the new epoch.  However, tasks with the same memory map as the
currently running task will get their goodness value boosted by 1.
The next task to run will be the first one found that has the same
memory map as the currently running task.  The check for 'still_running'
ensures that the the currently running task will be found first.

Not sure if this is by design, but this is what the code does.

Also, note that this is only true for UP kernels.  In SMP, there
are other factors to consider and a level of unpredictability
due to racing with other CPUs as a result of dropping the runqueue
lock during the 'recalculate' operation.

-- 
Mike Kravetz                                  kravetz@us.ibm.com
IBM Linux Technology Center       (we're not at Sequent anymore)

Re: scheduler policy

[Mike Kravetz]

On Thu, Sep 13, 2001 at 09:14:31PM -0700, Mike Kravetz wrote:
> On Thu, Sep 13, 2001 at 09:27:56PM -0500, shreenivasa H V wrote:
> > Hi,
> > 
> > In process scheduling, when an epoch ends because of the current process
> > completing its time quantum (and all the runnable ones having finished their
> > respective quantums), at the start of the new epoch, will the current running
> > process retain the cpu (assuming all the runnable ones are of the same
> > priority)?
> 
> Short answer, for UP kernels yes.
> 
> If all the tasks on the runqueue have the same priority (nice value),
> then they will all (almost) have the same goodness value at the start
> of the new epoch.  However, tasks with the same memory map as the
> currently running task will get their goodness value boosted by 1.
> The next task to run will be the first one found that has the same
> memory map as the currently running task.  The check for 'still_running'
> ensures that the the currently running task will be found first.

I thought about this some more and need to correct my original
response.  It is possible for another task to run after the start
of a new epoch.  This could come about due to the fact that the
runqueue lock is dropped during the 'recalculate' operation.  More
important to note is that during recalculate a window is open
where interrupts are enabled.  If a timer interrupt is serviced
in this window AFTER the counter value for the currently running
task has been adjusted, then the timer interrupt code will decrement
the counter value of the currently running task by 1.  In this
case the currently running task will have a lower goodness value
than other tasks that share the same memory map.  Therefore, some
other task with the same memory map would be chosen to run next.

In addition, when the runqueue lock is dropped during recalculate
tasks can be added to the runqueue which could have higher goodness
values (but the same priority) as the currently running task.
However, I'm not sure if these cases are within the constraints of
your original question.

My amended answer is most likely yes: possible no. :)

-- 
Mike Kravetz                                  kravetz@us.ibm.com
IBM Linux Technology Center       (we're not at Sequent anymore)