[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200704222109.24294.kernel@kolivas.org>
Date: Sun, 22 Apr 2007 21:09:23 +1000
From: Con Kolivas <kernel@...ivas.org>
To: Michael Gerdau <mgd@...hnosis.de>
Cc: ck@....kolivas.org,
linux kernel mailing list <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>, Mike Galbraith <efault@....de>,
Al Boldi <a1426z@...ab.com>,
Peter Williams <pwil3058@...pond.net.au>,
Nick Piggin <npiggin@...e.de>, Matt Mackall <mpm@...enic.com>,
Bill Huey <billh@...ppy.monkey.org>,
William Lee Irwin III <wli@...omorphy.com>,
Willy Tarreau <w@....eu>, Gene Heskett <gene.heskett@...il.com>
Subject: Re: [ck] [ANNOUNCE] Staircase Deadline cpu scheduler version 0.45
On Sunday 22 April 2007 18:02, Michael Gerdau wrote:
> Hi Con,
>
> I now have 2.6.21-rc7-sd-0.45 running on my Intel Core2 T7600 2.33
> machine and there is something I don't understand.
>
> For testing I have a Perl script that does some numbercrunching
> and runs a couple of hours.
>
> I have two scenarios
> a) start the job via loops in a shellscript
> b) start the job via a makefile (make -j 2)
> that I run in parallel.
>
> I watch the jobs via top and this is what I see:
> Job a) quickly gets about 100% (- 0-2) while job b) creates two
> perl jobs that both get 50% (- 0-2). I suppose it is expected
> behaviour that the single perl job created via a) gets same same
> share of the cpu as the two perl jobs created via b) together.
>
> However occasionally cpu drops to 33% for all three perl jobs
> while there is no other job visible in top (i.e. the sum drops
> from 200% to 100%). After some time this changes back to 100/50/50.
>
> How could this happen and would applying the other patch you
> mailed to Willy Tarreau help tracking that down ?
Thanks for report. That patch did not help Willy, and now you have confirmed
there still is an SMP balancing problem too where it doesn't seem to keep all
cpus busy. There's still a bug there in the smp balancing code and I'm
reviewing it madly trying to find it. If anyone else knows this balancing
code and is willing to help I'd be happy for feedback if they can see an
obvious error. Likely thing is the runqueue is not being weighted at all
despite being bust so the other runqueue doesn't try to take any tasks from
it.
--
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists