Re: [PATCH] Do not force shutdown/reboot to boot cpu.

[Ingo Molnar <mingo@kernel.org>]

* Robin Holt <holt@sgi.com> wrote:

> I had the machine booted as 512 cpus.
> I tweaked the kernel like this:
> 
> diff --git a/kernel/sys.c b/kernel/sys.c
> index 39c9c4a..b42bd4f 100644
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -368,8 +368,10 @@ EXPORT_SYMBOL(unregister_reboot_notifier);
>   */
>  void kernel_restart(char *cmd)
>  {
> -       kernel_restart_prepare(cmd);
> +       // kernel_restart_prepare(cmd);
>         disable_nonboot_cpus();
> +       enable_nonboot_cpus();
> +       return;
>         if (!cmd)
>                 printk(KERN_EMERG "Restarting system.\n");
>         else
> 
> perf record -a /sbin/reboot -d -f -n
> 
> The top of 'perf report' has:
> Events: 14M cycles
>     22.58%          swapper  [kernel.kallsyms]           [k] update_cfs_rq_blocked_load
>     10.52%          swapper  [kernel.kallsyms]           [k] load_balance
>      4.96%          swapper  [kernel.kallsyms]           [k] ktime_get
>      4.12%          swapper  [kernel.kallsyms]           [k] update_blocked_averages
>      3.55%          swapper  [kernel.kallsyms]           [k] idle_cpu
>      1.97%          swapper  [kernel.kallsyms]           [k] uv_read_rtc
>      0.98%          swapper  [kernel.kallsyms]           [k] rcu_process_gp_end
>      0.84%          swapper  [kernel.kallsyms]           [k] apic_timer_interrupt
>      0.84%          swapper  [kernel.kallsyms]           [k] __lock_text_start
>      0.84%          swapper  [kernel.kallsyms]           [k] _raw_spin_lock_irqsave
>      0.73%          swapper  [kernel.kallsyms]           [k] native_safe_halt
>      0.56%          swapper  [kernel.kallsyms]           [k] rcu_check_callbacks
>      0.56%          swapper  [kernel.kallsyms]           [k] native_write_msr_safe
>      0.44%          swapper  [kernel.kallsyms]           [k] cpumask_next_and
>      0.42%           reboot  [kernel.kallsyms]           [k] kmem_cache_alloc_node

Ok, so it looks profilable.

The result above is not surprising: most CPUs sit in idle and don't do anything, 
while the loop goes on, right?

The interesting thing to profile would be the parallel bring-down, with the 
simplest global lock solution you mentioned. In that case most CPUs should be 
doing 'something' all the time - maybe spinning on the lock, maybe something else, 
right?

Thanks,

	Ingo