Re: [Patch -v4 1/4] Migrate shutdown/reboot to boot cpu.

[Robin Holt]

> > > +{
> > > +	/* The boot cpu is always logical cpu 0 */
> > > +	int reboot_cpu_id = 0;
> > > +
> > > +	/* Make certain the cpu I'm about to reboot on is online */
> > > +	if (!cpu_online(reboot_cpu_id))
> > > +		reboot_cpu_id = smp_processor_id();
> > 
> > Shouldn't we pick the first online CPU instead, to make it deterministic?
> 
> Done.
> 
> 		reboot_cpu_id = cpumask_first(cpu_online_mask);
> 
> > Also, does this codepath prevent hotplug from going on in parallel?
> 
> Not sure.  I have not considered hotplug.  I will look that over when I
> am in the office.

OK.  I have been mulling this over for a bit and I don't think I
understand what you are asking.

I would expect that if an architecture depends upon a certain cpu for
shutdown/reboot/halt/suspend/hibernate and that support has been compiled
in, then the arch should be preventing that cpu from being removed.
I do not know how that would work and think that is far beyond the scope
of the initial problem I have been trying to solve.  If that is your
question, I certainly do not know how to address it.  I get the feeling
this is off your mark due to the "parallel" wording above.

The other question I think you might be asking is something about the
shutdown/reboot/halt task trying to migrate to a cpu which is in the
process of being off-lined.  I believe the code will "work" in that
we will have selected a cpu to migrate to, that migration may fail,
in which case our task remains on the current cpu, may succeed and the
cpu is immediately offlined, in which case the hotplug code should move
us to another cpu, or we complete the shutdown before the hotplug code
gets a chance to run, in which case it is irrelevant.

Have I addressed your concern?  Are you asking me to look into a method
for preventing the arch from hot removing the shutdown/reboot cpu?

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