Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 27 Jan 2009 16:28:30 +0100 Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > > But it's a general comment about fixing a general issue.  The 
> > > currently known case is not directly relevent; that it can happen and 
> > > it's restricting the use of this otherwise-general API is.
> > 
> > I think we should switch acpi-cpufreq to smp_call_function(), revert 
> > this stuff and ban the calling of work_on_cpu() under locks.
> 
> I agree that do_drv_read()/write() should be converted to 
> smp_function_call() (what it does is atomic: msr or PIO cycles).
> 
> Then work_on_cpu() can be removed for good, to not lure people into using 
> it. You seem to agree that work_on_cpu() is unfixable so it's far better 
> to offer nothing than to offer such a deceivingly named but fundamentally 
> limited facility.
> 

Well, I don't think it's unfixable.  But a full fix would, I think,
require a kernel thread for each callback invokation.  As dicussed
earlier, this could be optimised to only create the new kernel thread
if the keventd thread is presently off doing something else.

Is work_on_cpu() valuable enough to justify doing all that?  Dunno.
It appears to have six callers in three drivers at present, which is
quite a large number.

Or perhaps there's a smarter way of fixing it all.