Re: [PATCH] Avoid moving tasks when a schedule can be made.

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

Nick Piggin wrote:
> Ingo Molnar wrote:
>
> > * Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
>
> > > Oh, I forgot: Ingo once introduced some code to bail early (though 
> > > for different reasons and under different conditions), and this 
> > > actually was found to cause significant regressions in some database 
> > > workloads.
> >
> >
> >
> > well, we both did changes with that effect - pretty much any change in 
> > this area can cause a regression on _some_ workload ;) So there wont 
> > be any silver bullet.
>
> Well yes. Although specifically the bail-out-early stuff which IIRC
> you did... I wasn't singling you out in particular, I've broken the
> scheduler at _least_ as much as you have since starting work on it ;)

... and my point is that there is not much reason to introduce a
possible performance regression because of such a latency in an
artificial test case, especially when there are other sources of
unbound latency when dealing with large numbers of tasks (and on
uniprocessor too, eg. rwsem).

However, as an RT-tree thing obviously I have no problems with it,
but unless your interrupt thread is preemptible, then there isn't
much point because it can cause a similar latency (that your tools
won't detect) simply by running multiple times.

You really want isolcpus on SMP machines to really ensure load
balancing doesn't harm RT behaviour, yeah?

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/