[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7799.1239650838@turing-police.cc.vt.edu>
Date: Mon, 13 Apr 2009 15:27:18 -0400
From: Valdis.Kletnieks@...edu
To: linux-kernel@...r.kernel.org
Cc: Ingo Molnar <mingo@...e.hu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Mike Travis <travis@....com>, mm-commits@...r.kernel.org,
Rusty Russell <rusty@...tcorp.com.au>,
Dave Jones <davej@...hat.com>, Len Brown <lenb@...nel.org>
Subject: Re: mmotm 2009-04-10-02-21 uploaded - forkbombed by work_for_cpu
On Mon, 13 Apr 2009 10:27:49 PDT, Andrew Morton said:
> From: Andrew Morton <akpm@...ux-foundation.org>
>
> Atttempting to rid us of the problematic work_on_cpu(). Just use
> smp_call_fuction_single() here.
>
> This repairs a 10% sysbench(oltp)+mysql regression which Mike reported,
> due to
>
> commit 6b44003e5ca66a3fffeb5bc90f40ada2c4340896
> Author: Andrew Morton <akpm@...ux-foundation.org>
> Date: Thu Apr 9 09:50:37 2009 -0600
>
> work_on_cpu(): rewrite it to create a kernel thread on demand
>
> It seems that the kernel calls these acpi-cpufreq functions at a quite
> high frequency.
I put the one reverted commit back on (making it back into what was stock
mmotm-0410 that had the problem) and then applied this patch. I'm seeing
near-zero forks/second again, the CPU is at 1Ghz when idling (as it should
be), if I kick off 2 'for(;;)' cycle-suckers it goes to 2Ghz, And it even
puts 1 CPU at 1Ghz and the other at 2Ghz if there's only one running - I didn't
know a Core2 Duo could do that. ;)
So life is good again. ;)
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists