Date: Sun, 3 Jun 2012 10:54:07 +0100 From: Attilio Rao <attilio@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-acpi@freebsd.org, Mitsuru IWASAKI <iwasaki@jp.freebsd.org>, freebsd-arch@freebsd.org Subject: Re: cpu stopping [Was: preparation for x86/acpica/acpi_wakeup.c] Message-ID: <CAJ-FndAnx=UnxJCwLPtze7tu72wT4b%2Be2T_tHH%2Bpup-VaxfiTw@mail.gmail.com> In-Reply-To: <4FCB0FE5.4050607@FreeBSD.org> References: <20120603.002554.119853142.iwasaki@jp.FreeBSD.org> <CAJ-FndAfm4_XqFSwBqXK=cgWkE6YVrtkS5BbcH7zcRd-100xTw@mail.gmail.com> <4FCB0FE5.4050607@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2012/6/3 Andriy Gapon <avg@freebsd.org>: > on 03/06/2012 00:39 Attilio Rao said the following: >> The first thing to consider is that right now we only have 2 states >> for CPUs: started and stopped. These states are controlled by >> started_cpus and stopped_cpus masks respectively. It seems you really >> want to add an intermediate level among the 2 where you have: started >> -> suspended -> started -> suspended ... -> stopped and you need to >> expand the mechanism for dealing with started and stopped cpus to do >> that. I'm pretty sure this will be very helpful also for other >> architectures that want to do the same. > > As the first thing I must admit that I haven't looked at the patch :-) > > > But really I don't see why we need to differentiate between stopped and > suspended state as both of them ultimately mean exactly the same thing - CPUs > are spinning on some condition (and they are in a well-defined place and state). This is debeatable and I'm not sure I agree. At some point we may want to implement CPU on-the-fly suspension for CPUs which is a different event than "stopping" (where stopping will be "permanent stopping" and suspending will be "possible to recover suspension"). The important thing about this is that we need to expand our model in a way that it makes simple to add more states to the CPUs than simple started/stopped. Right now we don't have any architecture for this in place. > 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 > - the master signals slaves to enter the stop state > - the slaves execute the enter hook and start spinning on the release condition > - the master does whatever it wants to do in this special system state > - the master signals the slaves to resume > - the slave exit the spin loop and execute the exit hook > > We have almost all of this in place. Only now we have different IPIs and > different IPI handlers to do the job (cpustop_handler and cpususpend_handler). > I think that the hooks model should be more universal. For hook you mean like a rendezvous handler? I'm not sure I understand otherwise. > In my opinion, what really would deserve a completely independent path is the > hard-stop case. As this can be invoked nested to the other cases. E.g. exotic > situations like a breakpoint or a trap or a panic in the suspend or the normal > stop code paths. What I'm really interested is expanding our model in a way that it can handle multiple CPU states. Then it is just a matter of adding the right states and it is all trivial work. And however, as already mentioned, I'm not sure I would assimilate suspended = stopped. Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndAnx=UnxJCwLPtze7tu72wT4b%2Be2T_tHH%2Bpup-VaxfiTw>