cpu stopping

[Andriy Gapon]

on 06/06/2012 22:03 Mitsuru IWASAKI said the following:
> Hi,
> 
> I've created the patches of experimental implementation based on
> discussion so far.
> 
> http://people.freebsd.org/~iwasaki/acpi/cpustop_hook-20120606.diff
> 
> In acpi_wakeup.c, cpususpend_handler() and susppcbs are replaced with
> cpustop_handler() and stoppcbs.
> 
> This is for RELENG_9 and only for i386 but I think it's enough for the
> start.

I think that there is no need for DPCPU here.  All (affected) CPUs should see
the same hook, IMO.  At least I can not imagine the case where something else
would be required.
Also, it might make sense to provide a void pointer as a potential context for
for the context.  As Attilio has said before this has many similarities to what
smp_rendezvous does, just for different kind of situations.

> From: Andriy Gapon <avg at FreeBSD.org>
> Subject: Re: cpu stopping
> Date: Sun, 03 Jun 2012 22:45:33 +0300
> Message-ID: <4FCBBEDD.5000604 at FreeBSD.org>
> 
>>> Never mind :) What I'm trying to do in the patches is just to unify
>>> amd64/i386 independent part (acpi_wakeup.c) for the code maintenance,
>>> so please let's commit it first, then start re-design the
>>> cpususpend_handler().
>>
>> In no way I am trying to delay your work :)
>> Just shared my view on the design of cpu stopping code.
> 
> I got it :)
> 
>>>> My view of how this should work is:
>>>> - there can be only one master CPU that controls all other (slave) CPUs
>>>> - the master sets entry and exit hooks
>>>
>>> Entry hook for suspending might be
>>> ----
>>>                 ctx_fpusave(suspfpusave[cpu]);
>>>                 wbinvd();
>>>                 CPU_SET_ATOMIC(cpu, &stopped_cpus);
>>> ----
>>>
>>> and for stopping is
>>> ----
>>>         /* Indicate that we are stopped */
>>>         CPU_SET_ATOMIC(cpu, &stopped_cpus);
>>> ----
>>>
>>> Correct?
>>
>> Yes.  The only nit is that CPU_SET_ATOMIC(cpu, &stopped_cpus) could be part of
>> the wait loop prologue.  No need to duplicate it in each hook.
> 
> OK, I did so.
> 
> I hope the patch is not far from your idea.
> 
> Thanks!


-- 
Andriy Gapon