Date: Sun, 03 Jun 2012 22:35:14 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Attilio Rao <attilio@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: <4FCBBC72.8070209@FreeBSD.org> In-Reply-To: <CAJ-FndAnx=UnxJCwLPtze7tu72wT4b%2Be2T_tHH%2Bpup-VaxfiTw@mail.gmail.com> References: <20120603.002554.119853142.iwasaki@jp.FreeBSD.org> <CAJ-FndAfm4_XqFSwBqXK=cgWkE6YVrtkS5BbcH7zcRd-100xTw@mail.gmail.com> <4FCB0FE5.4050607@FreeBSD.org> <CAJ-FndAnx=UnxJCwLPtze7tu72wT4b%2Be2T_tHH%2Bpup-VaxfiTw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on 03/06/2012 12:54 Attilio Rao said the following: > 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"). Right, but that should operate on the level above the current code. I.e. first stop all slave CPUs, than set state of a target CPU (which includes global view of that state), then resume all other CPUs. > 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. I can't disagree with this, but I think that the current IPI-to-stop code is not a place for that. It's too low level. >> 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. Maybe, perhaps. I meant just a couple of function pointers. cpustop_restartfunc seems to be a better analogy. >> 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. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FCBBC72.8070209>