Re: Database regression due to scheduler changes ?

Nick Piggin
2005-11-08T02:14:14Z

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