On Wed, Apr 02, 2003 at 12:19:27AM +0200, Antonio Vargas wrote:
> 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.

Ok, second try...

I have a doubt, do we need any locking for struct user when reading/writing
his priority or when surfing the user_list?

Greets, Antnonio.