lkml.org 
[lkml]   [2008]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: fair group scheduler not so fair?
From
Date
On Fri, 2008-05-23 at 15:49 +0530, Srivatsa Vaddagiri wrote:
> On Fri, May 23, 2008 at 11:39:21AM +0200, Peter Zijlstra wrote:
> > On Fri, 2008-05-23 at 15:12 +0530, Srivatsa Vaddagiri wrote:
> > > On Thu, May 22, 2008 at 01:18:33PM -0700, Li, Tong N wrote:
> > > > Peter,
> > > >
> > > > I didn't look at your patches, but I thought you were flattening group
> > > > weights down to task-level so that the scheduler only looks at per-task
> > > > weights.
> > >
> > > Wouldnt that require task weight readjustment upon every fork/exit?
> >
> > If you were to do that - yes that would get you into some very serious
> > trouble.
> >
> > The route I've chosen is to basically recompute it every time I need the
> > weight. So every time I use a weight, I do:
>
> and which are those points when "you need the weight"?

eg. when computing the vruntime gain for this task, or when calculating
the slice.

Also when load-balancing, we do a similar thing through the h_load
stuff.

> Basically here's what I had in mind:
>
> Group A shares = 1024
> # of tasks in group A = 1 (T0)
>
> So T0 weight can be 1024.
>
> T0 now forks 1000 children. Ideally now,
> T0.weight = T1.weight = .... = T999.weight = 1024/1000
>
> If we don't change each task's weight like this, then group A will
> cumulatively get more share than it deserves.
>
> Are you saying you will change each task's weight lazily? If so how?

No, we leave it alone, but calculate the effective weight as seen from
the top for every time we apply a tasks weight to compute variables.

Basically all the calc_delta_*() stuff and the load balancer stuff.



\
 
 \ /
  Last update: 2008-05-23 12:21    [W:0.044 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site