Re: fairsched + O(1) process scheduler

[Antonio Vargas <wind@cocodriloo.com>]

On Tue, Apr 01, 2003 at 08:41:26AM -0800, William Lee Irwin III wrote:
> On Tue, Apr 01, 2003 at 02:51:59PM +0200, Antonio Vargas wrote:
> +
> +	if(fairsched){
> +		/* special processing for per-user fair scheduler */
> +	}
> 
> I suspect something more needs to happen there. =)

 :) I haven't even compiled with this patch, I'm just trying
to get around my ideas and thus I posted so that:

a. We had an off-site backup

b. People with experience could shout out loud if they saw
   some big-time silliness.

> I'd recommend a different approach, i.e. stratifying the queue into a
> user top level and a task bottom level. The state is relatively well
> encapsulated so it shouldn't be that far out.
> 
> 
> -- wli

I suspect you mean the scheduler runqueues?

My initial idea runs as follows:

a. On each array switch, we add some fixed value
   to user->ticks. (HZ perhaps?)

b. When adding, we cap at some maximum value.
   (2*HZ perhaps?)

c. On each timer tick, we decrement current->user->ticks.

d. When decrementing, if it's below zero we just
   end this thread. (user has expired)

e. When switching threads, we take the first one that belongs
   to a non-expired user. I think this can be done by sending
   the user-expired threads to the expired array, just like
   when they expire themselves.

I'll try to code this tonight, so I'll post later on
if I'm lucky.

I think this needs much less complexity for a first version,
but I would try what you propose if I get intimate enough
with the scheduler.

Greets, Antonio.