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

From: Valdis . Kletnieks
Date: Mon Apr 13 2009 - 11:14:55 EST


On Fri, 10 Apr 2009 02:22:23 PDT, akpm@xxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxx>
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: pgp00000.pgp
Description: PGP signature