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

[Rusty Russell <rusty@rustcorp.com.au>]

On Tue, 14 Apr 2009 01:34:23 am Linus Torvalds wrote:
> So the _real_ problem came through the commits like
> 
>     cpufreq: use work_on_cpu in acpi-cpufreq.c for drv_read and drv_write
>     cpumask: use work_on_cpu in acpi-cpufreq.c for read_measured_perf_ctrs
> 
> that were meant to reduce stack usage with big cpu masks. And sure, the 
> _old_ way of doing it was also stupid (it rescheduled the process to the 
> other CPU by using cpus_allowed()).

Reducing stack was main motivation, but old way was actually wrong: not only
can userspace see the affinity change, it can mess it up by setting it at the
same time.

It used to be reasonably quick, but forking a thread (to prevent locking
problems with keventd and yet avoid YA 1-thread-per-cpu) made it worse.

I'm no expert, but would life be more pleasant if the core cpufreq code
called these methods bound to an appropriate CPU?  They all seem to do these
tricks...

Cheers,
Rusty.