From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e28smtp04.in.ibm.com (e28smtp04.in.ibm.com [59.145.155.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "e28smtp04.in.ibm.com", Issuer "Equifax" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id F1BD9B6F1F for ; Wed, 12 Aug 2009 03:53:52 +1000 (EST) Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by e28smtp04.in.ibm.com (8.14.3/8.13.1) with ESMTP id n7BHriLI008417 for ; Tue, 11 Aug 2009 23:23:44 +0530 Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7BHrieN1626160 for ; Tue, 11 Aug 2009 23:23:44 +0530 Received: from d28av03.in.ibm.com (loopback [127.0.0.1]) by d28av03.in.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n7BHrhpN016649 for ; Wed, 12 Aug 2009 03:53:44 +1000 Date: Tue, 11 Aug 2009 23:23:41 +0530 From: Dipankar Sarma To: "Pallipadi, Venkatesh" Subject: Re: [PATCH 0/3] cpu: idle state framework for offline CPUs. Message-ID: <20090811175341.GA6328@in.ibm.com> References: <20090805142311.553.78286.stgit@sofia.in.ibm.com> <20090806015855.GA20596@sli10-desk.sh.intel.com> <20090809120818.GA1338@ucw.cz> <200908091522.02898.rjw@sisk.pl> <20090810081941.GA18649@elf.ucw.cz> <1249950137.11545.38184.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1249950137.11545.38184.camel@localhost.localdomain> Cc: "Brown, Len" , Peter Zijlstra , Gautham R Shenoy , "linux-kernel@vger.kernel.org" , "Rafael J. Wysocki" , Pavel Machek , "Li, Shaohua" , Ingo Molnar , "linuxppc-dev@lists.ozlabs.org" , "Darrick J. Wong" Reply-To: dipankar@in.ibm.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, Aug 10, 2009 at 05:22:17PM -0700, Pallipadi, Venkatesh wrote: > Also, I don't think using just the ACPI/BIOS supplied states in _CST is > right thing to do for offline. _CST is meant for C-state and BIOS may > not include some C-state in _CST if the system manufacturer thinks that > the latency is too high for the state to be used as a C-state. That > limitation applies for C-state as the cpu is expected to come out of > C-state often and execute code handle interrupts etc. But, that > restriction does not apply for offline online which is not as frequent > as C-state entry and it already has big latency with startup IPI, and a > whole baggage of CPU setup code. So, using BIOS CST info for CPU offline > state doesn't seem right. > > May be having (to pick a number) 3 possible offline states for all > platforms with one for halt equivalent and one for deepest possible that > CPU can handle and one for deepest possible that platform likes for > C-states may make sense. Will keeps things simpler in terms of usage > expectations and possibly reduce the misuse oppurtubity? Yes, I think we should let specific archs advertise a small set of possible offline states and let the cpu state be set to one of those only keeping the platform implementation robust. Here is variant of the original proposal from Gautham - /sys/devices/system/cpu/cpu/available_states For example, available state for an Intel platform could be exported as "online dealloc C1 C6" online = fully up dealloc = offline and de-allocated (as in virtualized environment) C1 = C1 or C1E halt C6 = C6 sleep /sys/devices/system/cpu/cpu/state Writing any of the available states to this file triggers transition to that state barring some transitions that are disallowed to keep things simple (e.g. dealloc cpus support only transition to online). /sys/devices/system/cpu/cpu/online Backward compatibility - online = 0 changes state to C6 or dealloc depending on the platform. online = 1 changes state to online. Would this make sense ? Thanks Dipankar