Question about scheduler changes from 2.2 to 2.4

Question about scheduler changes from 2.2 to 2.4

[Chris Friesen]

In the 2.2 scheduler there was a section that checked if the previous process
was still runnable and set it as the default next running process.  It looked
like this:

	if (prev->state == TASK_RUNNING)
	   goto still_running;
still_running_back:

With another chunk of code under still_running that set "c" and "next".

In 2.4 this seems to have been removed.  Can someone explain why?  I'm porting
some custom scheduler changes and want to make sure that I understand what's
going on in 2.4.

Thanks,

Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: Question about scheduler changes from 2.2 to 2.4

[Mike Kravetz]

On Mon, Apr 01, 2002 at 06:10:13PM -0500, Chris Friesen wrote:
> 
> In the 2.2 scheduler there was a section that checked if the previous process
> was still runnable and set it as the default next running process.  It looked
> like this:
> 
> 	if (prev->state == TASK_RUNNING)
> 	   goto still_running;
> still_running_back:
> 
> With another chunk of code under still_running that set "c" and "next".
> 
> In 2.4 this seems to have been removed.  Can someone explain why?  I'm porting
> some custom scheduler changes and want to make sure that I understand what's
> going on in 2.4.

In 2.2 and early 2.4 versions of the scheduler, the 'can_schedule'
macro rejected tasks that had the 'has_cpu' field set.  The logic
has been changed so that 'can_schedule' will return true for the
task which is still running on the current CPU.  Therefore, the
scan of all tasks on the runqueue will recognize/include the currently
running task.  This eliminates the need for the special 'still_running'
check noted above.

The logic should be the same as before.  The only difference would
be in the case where a task with identical goodness was found on the
runqueue before the current task.  In this case we would run the other
task instead of continuing with the current task.  In practice, this
doesn't happen enough to justify the special check.

-- 
Mike