Re: Database regression due to scheduler changes ?

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

David Lang wrote:
> On Tue, 8 Nov 2005, Nick Piggin wrote:
>
> > Long lived and memory intensive cloned or forked tasks will often
> > [but far from always :(] want to be put on another memory controller
> > from their siblings.
> >
> > On workloads where there are lots of short lived ones (some bloated
> > java programs), the load balancer should normally detect this and
> > cut the balance-on-fork/clone.
>
>
> although if the primary workload is short-lived tasks and you don't do 
> balance-on-fork/clone won't you have trouble ever balancing things? 
> (anything that you do move over will probably exit quickly and put you 
> right back where you started)

You'll have no trouble if things *need* to be balanced, because
that would imply the runqueue length average is significantly
above the lengths of other runqueues.

As far as the extra test goes, it's really a miniscule overhead
compared with the fork / clone cost itself, and can be really
worthwhile if we get it right.

> > Of course there are going to be cases where this fails. I haven't
> > seen significant slowdowns in tests, although I'm sure there would
> > be some at least small regressions. Have you seen any? Do you have
> > any tests in mind that might show a problem?
>
>
> even though people will point out that it's a brin-dead workload (that 
> should be converted to a state machine) I would expect that most 
> fork-per-connection servers would show problems if the work per 
> connection is small

Well it may be brain-dead, but if people use them (and they do)
then I would really be interested to see results.

I did testing with some things like apache and volanomark, however
I was not able to make out much difference on my setups. Though
obviously that's not to say that there won't be with other software
or other workloads / architectures etc.

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