Messages in this thread | | | From | Nikunj A Dadhania <> | Subject | Re: CPU Hotplug rework | Date | Tue, 10 Apr 2012 13:26:55 +0530 |
| |
On Mon, 9 Apr 2012 09:46:28 -0700, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote: > > > > 2. Read and understand the architecture-specific code, looking > > > for opportunities to consolidate additional function into > > > core code. > > > > > > a. Carry out any indicated consolidation. > > > > > > b. Convert all architectures to make use of the > > > consolidated implementation. > > > > > > Not started. Low priority from a big.LITTLE perspective. > > > > > > Recently this unexpectedly assumed high priority due to some scheduler > > changes and things got fixed up temporarily. And in that context, > > Peter Zijlstra gave some more technical pointers on what is wrong and needs > > to be done right. Link: https://lkml.org/lkml/2012/3/22/149 > > > > Nikunj (in CC) has offered to work with me on this consolidation. > > Very cool! I have added the following: > > ------------------------------------------------------------------------ > > CONSOLIDATE ARCHITECTURE-SPECIFIC CPU-HOTPLUG CODE > > 1. Ensure that all CPU_STARTING notifiers complete before the > incoming CPU is marked online (the blackfin architecture > fails to do this). > > 2. Ensure that interrupts are disabled throughout the CPU_STARTING > notifiers. Currently, blackfin, cris, m32r, mips, sh, sparc64, > um, and x86 fail to do this properly. > > 3. Ensure that all architectures that use CONFIG_USE_GENERIC_SMP_HELPERS > hold ipi_call_lock() over the entire CPU-online process. Currently, > alpha, arm, m32r, mips, sh, and sparc32 seem to fail to do this > properly. > > 4. Additional memory barriers are likely to be needed, for example, > an smp_wmb() after setting cpu_active and an smp_rmb() in > select_fallback_rq() before reading cpu_active. > > Srivatsa Bhat (srivatsa.bhat@linux.vnet.ibm.com) and Nikunj A Dadhania > (nikunj@linux.vnet.ibm.com) are taking on this work. > Sounds good :-)
Regards Nikunj
| |