On Fri, 27 Jul 2012 13:28:29 -0700, Suresh Siddha <[email protected]> wrote: > On Fri, 2012-07-27 at 17:08 +0930, Rusty Russell wrote: > > Paul McKenney points out: > > > > mean offline overhead is 6251/48=130.2 milliseconds. > > > > If I remove the alternatives_smp_switch() from the offline > > path [...] the mean offline overhead is 550/42=13.1 milliseconds > > > > Basically, we're never going to get those 120ms back, and the code is > > pretty messy. > > I am ok with this proposal. If I follow correctly, you are still > allowing the patching to UP happen on boot if there is only one online > cpu currently but a possiblity of multiple cpu's that can come online > later. Perhaps make this little more explicit in the changelog.
That's right. How's this: Subject: x86: don't ever patch back to UP if we unplug cpus. We still patch SMP instructions to UP variants if we boot with a single CPU, but not at any other time. In particular, not if we unplug CPUs to return to a single cpu. Paul McKenney points out: mean offline overhead is 6251/48=130.2 milliseconds. If I remove the alternatives_smp_switch() from the offline path [...] the mean offline overhead is 550/42=13.1 milliseconds Basically, we're never going to get those 120ms back, and the code is pretty messy. We get rid of: 1) The "smp-alt-once" boot option. It's actually "smp-alt-boot", the documentation is wrong. It's now the default. 2) The skip_smp_alternatives flag used by suspend. 3) arch_disable_nonboot_cpus_begin() and arch_disable_nonboot_cpus_end() which were only used to set this one flag. Signed-off-by: Rusty Russell <[email protected]> > Also, > > > + /* Patch to UP if other cpus not imminent. */ > > + if (noreplace_smp || num_present_cpus() == 1 || setup_max_cpus <= 1) { > > shouldn't this be > > if (!noreplace_smp && (num_present_cpus() == 1 || setup_max_cpus <= 1)) Yes, good point. > also, to be consistent with other checks, may be just use > "num_possible_cpus() == 1" check instead of "setup_max_cpus <= 1". I think that should work. Will test variations... Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
