Date: Sun, 3 Jun 2012 21:02:01 +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-FndAqFOy-jxXzxX_%2BRFBqD1k%2Bv62tDJzFic_==SWODi3VuQ@mail.gmail.com> In-Reply-To: <4FCBBC72.8070209@FreeBSD.org> 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> <4FCBBC72.8070209@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 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 an= d 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 inc= ludes > 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. =C2=A0It's too low level. Yeah, I was referring in particular to the handling of the masks and few other things (stoppcbs, which could be rebased as suspendpcbs for that, etc.). The point I'm really trying to make is: our model is very very biased on the on/off case (started/stopped) and we need to abstract this and have a framework for adding several CPU states. After you have an abstracted model, you can simply make several states easi= lly. This is not a simple work and it is also less simple for synchronization, which right now is very much simplified/unhandled. I would be very happy if you or Mitsuru plan to work on that. Attilio --=20 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-FndAqFOy-jxXzxX_%2BRFBqD1k%2Bv62tDJzFic_==SWODi3VuQ>