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.
This archive was generated by hypermail 2b29 : Mon Apr 07 2003 - 22:00:16 EST