Re: [patch 2/5] x86_64: CPU hotplug support.

[Ashok Raj <ashok.raj@intel.com>]

On Fri, Jun 03, 2005 at 10:01:55AM +0800, Shaohua Li wrote:
> On Thu, 2005-06-02 at 16:33 -0700, Ashok Raj wrote:
> > On Thu, Jun 02, 2005 at 02:19:55PM -0600, Zwane Mwaikambo wrote:
> > > On Thu, 2 Jun 2005, Ashok Raj wrote:
> > > 
> > > > @@ -445,8 +477,10 @@ void __cpuinit start_secondary(void)
> > > >  	/*
> > > >  	 * Allow the master to continue.
> > > >  	 */
> > > > +	lock_ipi_call_lock();
> > > >  	cpu_set(smp_processor_id(), cpu_online_map);
> > > >  	mb();
> > > > +	unlock_ipi_call_lock();
> > > 
> > > What's that? Is this another smp_call_function race workaround? I thought 
> > > there was an additional patch to avoid the broadcast.
> > 
> > The other patch avoids sending to offline cpu's, but we read cpu_online_map
> > and clear self bit in smp_call_function. If a cpu comes online, dont we 
> > want this cpu to take part in smp_call_function?
> > 
> > if we dont care about this new CPU participating, and if cpu_set() is atomic
> > (for all NR_CPUS) we dont need to hold call_lock, otherwise we need to hold
> > this as well.
> If a CPU isn't online, why should it participates it? If it should
> participate it, it also might do the similar thing before set cpu
> online.

Good point. I was just trying to include the just arrived cpu, in the 
set, but i can convince myself that this would be any real value to include
this newly arrived cpu in that case. I can drop it.

> Some places which really care about it such as smp_send_stop should hold
> cpucontrol semaphore to me.

panic() ends up calling smp_send_stop(), i dont think we could hold a sema
in that path if we end up calling from intr context.

probably from callers of stop_machine/restart we could add lock_cpu_hotplug
not too sure how useful that would be though.
> 
> Thanks,
> Shaohua
> 

-- 
Cheers,
Ashok Raj
- Open Source Technology Center