Re: mmotm 2009-04-10-02-21 uploaded - forkbombed by work_for_cpu

[Valdis.Kletnieks@vt.edu]

[-- Attachment #1: Type: text/plain, Size: 2204 bytes --]

On Fri, 10 Apr 2009 02:22:23 PDT, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2009-04-10-02-21 has been uploaded to
> 
>    http://userweb.kernel.org/~akpm/mmotm/

My system is reporting 70-90 forks per second, 'lastcomm' is reporting:

work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37
work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37
work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37
work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37
work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37
work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37
work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37
work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37
work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37

(and about 100K more of same).

Reverting this commit made the forks go away:

commit 6b44003e5ca66a3fffeb5bc90f40ada2c4340896
Author: Andrew Morton <akpm@linux-foundation.org>
Date:   Thu Apr 9 09:50:37 2009 -0600

    work_on_cpu(): rewrite it to create a kernel thread on demand

No, I don't see why this generated a user-visible fork and accounting
record to be cut.  Maybe that's a normal side effect of kthread_create()
that I've never noticed because kthreads rarely exit, especially not at
90/sec.  I also don't know who's *calling* work_on_cpu() 90 times a
second, but I suspect it's this:

    This is not terribly fast, but the only current caller of work_on_cpu() is
    pci_call_probe().

Umm. No.

% find . -name '*.c' | xargs grep -l work_on_cpu 2> /dev/null 
./arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
./arch/x86/kernel/microcode_core.c
./arch/x86/kernel/acpi/cstate.c
./arch/x86/kernel/apm_32.c
./kernel/workqueue.c
./drivers/acpi/processor_throttling.c
./drivers/pci/pci-driver.c

Probable cause for my problem:

arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c calls work_on_cpu(). We get into a
state where we have enough activity to kick us to a high CPU speed, and then
the activity of writing 90 acct records per sec keeps us there - with continual
callbacks to see if we can drop the CPU speed.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]