From owner-freebsd-arch@FreeBSD.ORG Sun Jun 3 19:35:26 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53EEA106566B; Sun, 3 Jun 2012 19:35:26 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3964C8FC1B; Sun, 3 Jun 2012 19:35:25 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA01101; Sun, 03 Jun 2012 22:35:16 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SbGa4-000Mor-3y; Sun, 03 Jun 2012 22:35:16 +0300 Message-ID: <4FCBBC72.8070209@FreeBSD.org> Date: Sun, 03 Jun 2012 22:35:14 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Attilio Rao References: <20120603.002554.119853142.iwasaki@jp.FreeBSD.org> <4FCB0FE5.4050607@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, Mitsuru IWASAKI , freebsd-arch@FreeBSD.org Subject: Re: cpu stopping [Was: preparation for x86/acpica/acpi_wakeup.c] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 19:35:26 -0000 on 03/06/2012 12:54 Attilio Rao said the following: > 2012/6/3 Andriy Gapon : >> 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