cpu stopping
Andriy Gapon
avg at FreeBSD.org
Wed Jun 6 20:16:20 UTC 2012
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
More information about the freebsd-acpi
mailing list