All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hsin-Yi Wang <hsinyi@chromium.org>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
	Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Jiri Kosina <jkosina@suse.cz>,
	Pavankumar Kondeti <pkondeti@codeaurora.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Aaro Koskinen <aaro.koskinen@nokia.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Guenter Roeck <groeck@chromium.org>,
	Stephen Boyd <swboyd@chromium.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH RFC v3 1/3] reboot: support hotplug CPUs before reboot
Date: Mon, 13 Jan 2020 23:12:09 +0800	[thread overview]
Message-ID: <CAJMQK-gXbs+B8HCdKHvgDf3NpP_YfkheMXzzWHMcoTzZuP-9hw@mail.gmail.com> (raw)
In-Reply-To: <87r203plr7.fsf@vitty.brq.redhat.com>

On Mon, Jan 13, 2020 at 8:46 PM Vitaly Kuznetsov <vkuznets@redhat.com> wrote:

Thanks for your comments.

> > +config REBOOT_HOTPLUG_CPU
> > +     bool "Support for hotplug CPUs before reboot"
> > +     depends on HOTPLUG_CPU
> > +     help
> > +       Say Y to do a full hotplug on secondary CPUs before reboot.
>
> I'm not sure this should be a configurable option, e.g. in case this is
> a good approach in general, why not just use CONFIG_HOTPLUG_CPU in the
> code?
>
In v2 it uses CONFIG_HOTPLUG_CPU, but I think adding another config is
more flexible. Maybe there are some architecture that supports
HOTPLUG_CPU but doesn't want to do full cpu hotplug before reboot.
(Eg. doing cpu hotplug would make reboot process slower.)
> > +
> >  config HAVE_OPROFILE
> >       bool
> >
> > diff --git a/include/linux/cpu.h b/include/linux/cpu.h
> > index 1ca2baf817ed..3bf5ab289954 100644
> > --- a/include/linux/cpu.h
> > +++ b/include/linux/cpu.h
> > @@ -118,6 +118,9 @@ extern void cpu_hotplug_disable(void);
> >  extern void cpu_hotplug_enable(void);
> >  void clear_tasks_mm_cpumask(int cpu);
> >  int cpu_down(unsigned int cpu);
> > +#if IS_ENABLED(CONFIG_REBOOT_HOTPLUG_CPU)
> > +extern void offline_secondary_cpus(int primary);
> > +#endif
> >
> >  #else /* CONFIG_HOTPLUG_CPU */
> >
> > diff --git a/kernel/cpu.c b/kernel/cpu.c
> > index 9c706af713fb..52afc47dd56a 100644
> > --- a/kernel/cpu.c
> > +++ b/kernel/cpu.c
> > @@ -1057,6 +1057,25 @@ int cpu_down(unsigned int cpu)
> >  }
> >  EXPORT_SYMBOL(cpu_down);
> >
> > +#if IS_ENABLED(CONFIG_REBOOT_HOTPLUG_CPU)
> > +void offline_secondary_cpus(int primary)
> > +{
> > +     int i, err;
> > +
> > +     cpu_maps_update_begin();
> > +
> > +     for_each_online_cpu(i) {
> > +             if (i == primary)
> > +                     continue;
> > +             err = _cpu_down(i, 0, CPUHP_OFFLINE);
> > +             if (err)
> > +                     pr_warn("Failed to offline cpu %d\n", i);
> > +     }
> > +     cpu_hotplug_disabled++;
> > +
> > +     cpu_maps_update_done();
> > +}
> > +#endif
>
> This looks like a simplified version of freeze_secondary_cpus(), can
> they be merged?
>
Comparing to freeze_secondary_cpus(),  I think it's not necessary to
check pm_wakeup_pending() before _cpu_down() here. Thus it doesn't
need to depend on CONFIG_PM_SLEEP_SMP.
Also I think it could continue to offline other CPUs even one fails,
while freeze_secondary_cpus() would stop once it fails on offlining
one CPU.
Based on these differences, I didn't use freeze_secondary_cpus() here.
As for merging the common part, it might need additional flags to
handle the difference, which might lower the readability.
>

  reply	other threads:[~2020-01-13 15:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-13 12:01 [PATCH RFC v3 0/3] support hotplug CPUs before reboot Hsin-Yi Wang
2020-01-13 12:01 ` [PATCH RFC v3 1/3] reboot: " Hsin-Yi Wang
2020-01-13 12:46   ` Vitaly Kuznetsov
2020-01-13 15:12     ` Hsin-Yi Wang [this message]
2020-01-13 15:57       ` Vitaly Kuznetsov
2020-01-13 17:00         ` Hsin-Yi Wang
2020-01-13 12:01 ` [PATCH RFC v3 2/3] arm64: defconfig: enable REBOOT_HOTPLUG_CPU Hsin-Yi Wang
2020-01-13 12:01 ` [PATCH RFC v3 3/3] x86: " Hsin-Yi Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJMQK-gXbs+B8HCdKHvgDf3NpP_YfkheMXzzWHMcoTzZuP-9hw@mail.gmail.com \
    --to=hsinyi@chromium.org \
    --cc=aaro.koskinen@nokia.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=groeck@chromium.org \
    --cc=jkosina@suse.cz \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pkondeti@codeaurora.org \
    --cc=swboyd@chromium.org \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=zhenzhong.duan@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.