Hi,

On Thu, 13 Sep 2007, Peter Zijlstra wrote:

quoted text
> >  There's a good reason 
> > I put that much effort into maintaining a good, but still cheap average, 
> > it's needed for a good task placement.
> 
> While I agree that having this average is nice, your particular
> implementation has the problem that it quickly overflows u64 at which
> point it becomes a huge problem (a CPU hog could basically lock up your
> box when that happens).

If you look at the math, you'll see that I took the overflow into account, 
I even expected it. If you see this effect in my implementation, it would 
be a bug.

quoted text
> >  There is of course more than one 
> > way to implement this, so you'll have good chances to simply reimplement 
> > it somewhat differently, but I'd be surprised if it would be something 
> > completely different.
> 
> Currently we have 2 approximations in place:
> 
>   (leftmost + rightmost) / 2
> 
> and
> 
>   leftmost + period/2   (where period should match the span of the tree)
> 
> neither are perfect but they seem to work quite well.

You need more than two busy loops. 
There's a reason I implemented a simple simulator first, so I could 
actually study the scheduling behaviour of different load situations. That 
doesn't protect from all surprises of course, but it gives me the 
necessary confidence the scheduler will work reasonably even in weird 
situations.
From these tests I already know that your approximations only work with 
rather simple loads.

bye, Roman
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/