From owner-freebsd-arch@FreeBSD.ORG Sun Jun 3 09:54:10 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A6AC106564A; Sun, 3 Jun 2012 09:54:10 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7908D8FC08; Sun, 3 Jun 2012 09:54:09 +0000 (UTC) Received: by laai10 with SMTP id i10so3072293laa.13 for ; Sun, 03 Jun 2012 02:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Pr4Hnj2HezsD1rehQuPsqCPcosSqnis1+4C86gL9b50=; b=WvH6NwwC/Ix+vXjpZx/aZxicqBDNEqCfqd2xK20qQaEu33kbIpese2sz68YUzszipm 3iC62advSifR+flumJlcijLxoann4oMUSJsWiS4aBf1ThZqh66wqr8Z1ckOfknXmrR0R 27lE/v8a/9PikykdUrdKwkIumen/4o6Al3ppoTRGfJ3rTh5QFT+LgZUsJz5153RxV5sf yOE9HT4zKJNDeaekISQHfWln1LkxLOieH/iXjzjMcnlV5c/wufDh8xutg6NdjNFcEl/G wdiwwi9aeF6F2kPIE7h5r8gLTYxgm1nj+EJS1DY4atHi1ME3wsoP/kYCKZjtY6EqlCHl fvIA== MIME-Version: 1.0 Received: by 10.152.103.11 with SMTP id fs11mr8689233lab.23.1338717248070; Sun, 03 Jun 2012 02:54:08 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Sun, 3 Jun 2012 02:54:07 -0700 (PDT) In-Reply-To: <4FCB0FE5.4050607@FreeBSD.org> References: <20120603.002554.119853142.iwasaki@jp.FreeBSD.org> <4FCB0FE5.4050607@FreeBSD.org> Date: Sun, 3 Jun 2012 10:54:07 +0100 X-Google-Sender-Auth: qSLZcHBUQgn9exkzIhnujbmC38s Message-ID: From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 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 09:54:10 -0000 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"). 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