Re: Remove hotplug cpu crap from cpufreq.

[Dipankar Sarma <dipankar@in.ibm.com>]

Dave,

On Wed, Nov 01, 2006 at 06:32:50PM -0500, Dave Jones wrote:
> On Wed, Nov 01, 2006 at 03:09:52PM -0800, Linus Torvalds wrote:
> 
>  > Hmm. People _have_ given a damn, and I think you were even cc'd.
> 
> You're right. In my defense, that stuff arrived the day I went
> on vacation for two weeks, and I subsequently forgot all about it.
> Looking back over that thread though, a few people seemed to pick a
> number of holes in the patches, and there are some real gems in that
> thread like.

Have you looked at this patchset - http://lkml.org/lkml/2006/10/26/65 ?
This is the latest patchset posted last week and I haven't seen any 
comments on it.

>  > Really, the hotplug locking rules are fairly simple-
>  > 
>  > 1. If you are in cpu hotplug callback path, don't take any lock.
> 
> Which is just great, as afair, the cpufreq locks were there _before_
> someone liberally sprinkled lock_cpu_hotplug() everywhere.

This one has a major *cleanup* of cpufreq code including removel
of unncessary lock_cpu_hotplug() from cpufreq.

> 
> From what I can tell from looking at that thread back in August,
> it went on for a while with a number of people picking holes in the
> proposed patches, but there wasn't any reposted after that, and
> certainly nothing that ended up in -mm.
> 
> _something_ needs to be done. If someone wants to fix it, great, but
> until we see something mergable, we're left in this half-assed state
> which is freaking people out.

There are two approaches - Implicit hotplug callback order-based locking
as Andrew has done or keep the current cpu hotplug "lock" semantics
and just use a better lock (RCU-based) with cpu-local access in
the fast path. Gautham's patchset does the latter. lock_cpu_hotplug() is 
a misnomer, we should probably use get_cpu_hotplug() and 
put_cpu_hotplug() there.

Thanks
Dipankar