lkml.org 
[lkml]   [2005]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch 2/5] x86_64: CPU hotplug support.
From
Date
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.
Some places which really care about it such as smp_send_stop should hold
cpucontrol semaphore to me.

Thanks,
Shaohua

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-06-03 03:59    [W:0.314 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site