From owner-freebsd-arch@FreeBSD.ORG Sun Jun 3 20:02: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 9FBBC1065745; Sun, 3 Jun 2012 20:02: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 A3F3A8FC1A; Sun, 3 Jun 2012 20:02:09 +0000 (UTC) Received: by laai10 with SMTP id i10so3262639laa.13 for ; Sun, 03 Jun 2012 13:02:01 -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 :content-transfer-encoding; bh=dUPpHTdTJTdWNZBt33McuZiSIzerq38ci95MZLizuIg=; b=ysizMijAvLhD1tY3B6qSu1V1CfNTU92DMr4EGBk+nYjYr+s9XZKnUc3M17gT2pzYJp O9KLbi3YI5KIdPtoD7CEgU9c2/kHdPLM8qpSL/UWydFcoePPSjW14l87IOZUO1Xypl6V te7tQYsfeztiGf8RKcONNtnAYOUw0o0A2rt/NuwapqjqQuJmXDOtCx7Qon4NUPcsyE5t mWRiiO0b6sCMu6jHeJuh56ipp6ki4HPslwVWjGUxtYcGGxBCsBD3n/wUl4/Xm22kWWfu xUDIR2KWaNdHleZLuC2aGDAC3D5Dkxtoqlf9P8ffzGdi//Skmz5ROJ1LnDj5BL/Ej7fV rewA== MIME-Version: 1.0 Received: by 10.152.103.11 with SMTP id fs11mr9876014lab.23.1338753721887; Sun, 03 Jun 2012 13:02:01 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Sun, 3 Jun 2012 13:02:01 -0700 (PDT) In-Reply-To: <4FCBBC72.8070209@FreeBSD.org> References: <20120603.002554.119853142.iwasaki@jp.FreeBSD.org> <4FCB0FE5.4050607@FreeBSD.org> <4FCBBC72.8070209@FreeBSD.org> Date: Sun, 3 Jun 2012 21:02:01 +0100 X-Google-Sender-Auth: xSOxkHrJHCFZkowbHu9KLCDOs4E Message-ID: From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 20:02:10 -0000 2012/6/3 Andriy Gapon : > 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 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