Re: [patch] sched: improve pinned task handling again!

[Nick Piggin <nickpiggin@yahoo.com.au>]

Siddha, Suresh B wrote:
> On Sat, Apr 02, 2005 at 01:11:20PM +1000, Nick Piggin wrote:
>
> > How important is this? Any application to real workloads? Even if
> > not, I agree it would be nice to improve this more. I don't know
> > if I really like this approach - I guess due to what it adds to
> > fastpaths.
>
>
> Ken initially observed with older kernels(2.4 kernel with Ingo's sched), it was 
> happening with few hundred processes. 2.6 is not that bad and it improved
> with recent fixes. It is not very important. We want to raise the flag
> and see if we can comeup with a decent solution.

OK.

> We changed nr_running from "unsigned long" to "unsigned int". So on 64-bit
> architectures, our change to fastpath is not a big deal.

Yeah I see. You are looking at data from remote runqueues a bit
more often too, although I think they're all places where the
remote cacheline would have already been touched recently.

> > Now presumably if the all_pinned logic is working properly in the
> > first place, and it is correctly causing balancing to back-off, you
> > could tweak that a bit to avoid livelocks? Perhaps the all_pinned
> > case should back off faster than the usual doubling of the interval,
> > and be allowed to exceed max_interval?
>
>
> Coming up with that number(how much to exceed) will be a big task. It depends
> on number of cpus and how fast they traverse the runqueue,...

Well we probably don't need to really fine tune it a great deal.
Just pick a lage number that should work OK on most CPU speeds
and CPU counts.

--
SUSE Labs, Novell Inc.

-
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/