lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ