From randy.fishel@sun.com Wed Feb 18 11:45:50 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1IJjoAO006715 for ; Wed, 18 Feb 2009 11:45:50 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1IJjf0O024756 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 18 Feb 2009 19:45:48 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFA0010T1KBQS00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Feb 2009 12:45:47 -0700 (MST) Received: from grimmy.sfbay.sun.com ([129.146.108.114]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFA00HEM1K9O0A0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Feb 2009 12:45:45 -0700 (MST) Received: from grimmy.eng.sun.com (localhost [127.0.0.1]) by grimmy.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1IJUe9S006186; Wed, 18 Feb 2009 11:30:40 -0800 (PST) Received: from localhost (randyf@localhost) by grimmy.eng.sun.com (8.13.8+Sun/8.13.8/Submit) with ESMTP id n1IJUeNL006183; Wed, 18 Feb 2009 11:30:40 -0800 (PST) Date: Wed, 18 Feb 2009 11:30:39 -0800 (PST) From: Randy Fishel Subject: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] X-X-Sender: randyf@grimmy To: PSARC-ext@sun.com Cc: jiang.liu@intel.com, frank.wang@intel.com, tesla-dev@opensolaris.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Authentication-warning: grimmy.eng.sun.com: randyf owned process doing -bs User-Agent: Alpine 1.10 (GSO 962 2008-03-14) Status: RO Content-Length: 4574 I am sponsoring the following fasttrack for Gerry Liu from Intel. It proposes a notification interface initially used and provided by memory power management work done by Intel engineers in the OpenSolaris Tesla project. It requests micro/patch release binding. All interfaces will have a "Volatile" stability. Timeout is February 25th. This project, release binding, and stability has been reviewed and approved by the OpenSolaris Tesla project leaders and contributors. 1. Introduction 1.1. Project/Component Working Name: CPU idle notification interface 1.2. Name of Document Author/Supplier: Author: Gerry Liu 1.3. Date of This Document: November 16, 2008 4. Technical Description: 4.1. Problem A CPU idle notification mechanism is needed to signal other components which are interested in the CPU idle state change events when CPU enters/exits idle state. This mechanism could be used by following components: A) Memory power saving driver B) Lazy TLB flush on x86 system C) CPU power management framework 4.2. Proposal We propose to add following data structures/interfaces to OpenSolaris kernel. 4.2.1 CPU idle notification information data structure typedef struct cpu_idle_info { int ci_flags; int ci_intr_count; /* Interrupt count. */ int ci_idle_state; /* Idle state to enter. */ hrtime_t ci_idle_latency; /* Idle round trip latency. */ hrtime_t ci_max_idle_time; /* Predicted max idle time. */ hrtime_t ci_last_idle_time;/* Last idle period. */ hrtime_t ci_last_busy_time;/* Last busy period. */ } cpu_idle_info_t; This structure is used to pass CPU idle information to callbacks. It could be extended to support architecture/platform specific information in future. Valid flags for cpu_idle_info_t: CPU_IDLE_CI_FLAG_IDLE_STATE: field ci_idle_state is valid. CPU_IDLE_CI_FLAG_IDLE_LATENCY: field ci_idle_latency is valid. CPU_IDLE_CB_FLAG_MAX_IDLE_TIME: field ci_max_idle_time is valid. 4.2.2 Prototype of entering idle state notification callback typedef void (*cpu_idle_enter_cbfn)(void *arg, cpu_idle_info_t *infop); Entering idle state notification callback must obey all constraints which applies to idle thread becuase it will be called in idle thread context. Argument arg is the parameter passed in when registering callback. 4.2.3 Prototype of exiting idle state notification callback typedef void (*cpu_idle_exit_cbfn)(void *arg, int flags); Exiting idle state notification callback will be called in idle thread context or interrupt context. There are flags to distinguish the calling contexts. arg is the parameter passed in when registering callback. Valid flags for exiting idle state notification callback: CPU_IDLE_CB_FLAG_INTR: called in interrupt context CPU_IDLE_CB_FLAG_IDLE: called in idle thread context 4.2.4 CPU idle notification callback data structures typedef struct cpu_idle_callback { int version; cpu_idle_enter_cbfn idle_enter; cpu_idle_exit_cbfn idle_exit; } cpu_idle_callback_t; At least one of idle_enter and idle_exit is non-NULL. 4.2.5. Register CPU idle notification callback int cpu_idle_register_callback(uint_t priority, cpu_idle_callback_t *callbackp, void *arg, void **hdlpp); This interface registers a callback to be called when CPU idle state changes. All registered callbacks will be called in priority order from high to low when CPU enters idle state and will be called in reverse order when CPU exits idle state. Argument priority is used to determine the calling order of registered callbacks. Argument arg will be passed back to registered callback and how to use it is determined by callback. 4.2.6. Deregister CPU notification callback int cpu_idle_unregister_callback(uint_t priority, cpu_idle_callback_t *callbackp, void *arg, void *hdlp); This interface deregisters a registered callback. 4.2.7. Signal entering idle state event void cpu_idle_enter(cpu_idle_info_t *infop); This interface notifies idle notification subsystem that a specific CPU is entering into idle state. 4.2.8. Signal exiting idle state event void cpu_idle_exit(int flags); This interface notifies idle notification subsystem that a specific CPU is exiting from idle state. 6. Resources and Schedule: 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Artem.Kachitchkin@sun.com Wed Feb 18 11:59:51 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1IJxo5r007408 for ; Wed, 18 Feb 2009 11:59:50 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1IJxm98005763; Wed, 18 Feb 2009 11:59:50 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFA00A3727QAG00@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Feb 2009 11:59:50 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFA008WX27NE590@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Feb 2009 11:59:47 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1IJxlCg007163; Wed, 18 Feb 2009 11:59:47 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFA00B000OURM00@fe-sfbay-09.sun.com>; Wed, 18 Feb 2009 11:40:52 -0800 (PST) Received: from [129.146.104.83] ([unknown] [129.146.104.83]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFA00M5B1BT02H0@fe-sfbay-09.sun.com>; Wed, 18 Feb 2009 11:40:41 -0800 (PST) Date: Wed, 18 Feb 2009 11:59:04 -0800 From: Artem Kachitchkine Subject: Re: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] In-reply-to: Sender: Artem.Kachitchkin@sun.com To: Randy Fishel Cc: PSARC-ext@sun.com, jiang.liu@intel.com, frank.wang@intel.com, tesla-dev@opensolaris.org Message-id: <499C6888.1080802@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: User-Agent: Thunderbird 2.0.0.18 (X11/20081215) Status: RO Content-Length: 907 > 4.2.5. Register CPU idle notification callback > int cpu_idle_register_callback(uint_t priority, > cpu_idle_callback_t *callbackp, void *arg, void **hdlpp); > This interface registers a callback to be called when CPU idle state > changes. All registered callbacks will be called in priority order > from high to low when CPU enters idle state and will be called in > reverse order when CPU exits idle state. > Argument priority is used to determine the calling order of > registered callbacks. > Argument arg will be passed back to registered callback and how to > use it is determined by callback. What are possible return values and their meaning? On architectures that do not implement this functionality (sparc?), will these functions exist, i.e. will consumers be #ifdef free, and if so, what's the behavior: fail callback registration, or succeed but never callback. -Artem From gdamore@sun.com Wed Feb 18 12:20:44 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1IKKh3Z027938 for ; Wed, 18 Feb 2009 12:20:43 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1IKKcn1026000; Wed, 18 Feb 2009 20:20:40 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFA0052F36E7I00@brm-avmta-1.central.sun.com>; Wed, 18 Feb 2009 13:20:38 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFA00H1A36BNWF0@brm-avmta-1.central.sun.com>; Wed, 18 Feb 2009 13:20:38 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1IKKUw8017765; Wed, 18 Feb 2009 12:20:35 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFA00M002SCTW00@fe-sfbay-10.sun.com>; Wed, 18 Feb 2009 12:20:33 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFA007U03689LD0@fe-sfbay-10.sun.com>; Wed, 18 Feb 2009 12:20:32 -0800 (PST) Date: Wed, 18 Feb 2009 12:20:32 -0800 From: "Garrett D'Amore" Subject: Re: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] In-reply-to: Sender: Garrett.Damore@sun.com To: Randy Fishel Cc: PSARC-ext@sun.com, jiang.liu@intel.com, frank.wang@intel.com, tesla-dev@opensolaris.org Message-id: <499C6D90.6020603@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 5420 Randy Fishel wrote: > I am sponsoring the following fasttrack for Gerry Liu from Intel. It > proposes a notification interface initially used and provided by memory > power management work done by Intel engineers in the OpenSolaris > Tesla project. > > It requests micro/patch release binding. All interfaces will have > a "Volatile" stability. Timeout is February 25th. > > This project, release binding, and stability has been reviewed and > approved by the OpenSolaris Tesla project leaders and contributors. > > > > 1. Introduction > 1.1. Project/Component Working Name: > CPU idle notification interface > > 1.2. Name of Document Author/Supplier: > Author: Gerry Liu > > 1.3. Date of This Document: > November 16, 2008 > > 4. Technical Description: > 4.1. Problem > A CPU idle notification mechanism is needed to signal other > components which are interested in the CPU idle state change events > when CPU enters/exits idle state. This mechanism could be used by > following components: > A) Memory power saving driver > B) Lazy TLB flush on x86 system > C) CPU power management framework > > 4.2. Proposal > We propose to add following data structures/interfaces to > OpenSolaris kernel. > > 4.2.1 CPU idle notification information data structure > typedef struct cpu_idle_info { > int ci_flags; > int ci_intr_count; /* Interrupt count. */ > int ci_idle_state; /* Idle state to enter. */ > hrtime_t ci_idle_latency; /* Idle round trip latency. */ > hrtime_t ci_max_idle_time; /* Predicted max idle time. */ > hrtime_t ci_last_idle_time;/* Last idle period. */ > hrtime_t ci_last_busy_time;/* Last busy period. */ > } cpu_idle_info_t; > This structure is used to pass CPU idle information to callbacks. > It could be extended to support architecture/platform specific > information in future. > Valid flags for cpu_idle_info_t: > CPU_IDLE_CI_FLAG_IDLE_STATE: field ci_idle_state is valid. > CPU_IDLE_CI_FLAG_IDLE_LATENCY: field ci_idle_latency is valid. > CPU_IDLE_CB_FLAG_MAX_IDLE_TIME: field ci_max_idle_time is valid. > > Is there a reason that a single structure is required (are some of these fields linked and need to be dealt with atomically?) If not, then I'd prefer to have separate name-value pairs for each kind of datum. Perhaps something like a named property interface. My experience is that structures with lots of detail tend to have problems evolving over time (you wind up with lots of "reserved" or "obsolete" fields...) > typedef void (*cpu_idle_enter_cbfn)(void *arg, > cpu_idle_info_t *infop); > Entering idle state notification callback must obey all constraints > which applies to idle thread becuase it will be called in idle > thread context. > Argument arg is the parameter passed in when registering callback. > > 4.2.3 Prototype of exiting idle state notification callback > typedef void (*cpu_idle_exit_cbfn)(void *arg, int flags); > Exiting idle state notification callback will be called in idle > thread context or interrupt context. There are flags to distinguish > the calling contexts. > arg is the parameter passed in when registering callback. > Valid flags for exiting idle state notification callback: > CPU_IDLE_CB_FLAG_INTR: called in interrupt context > CPU_IDLE_CB_FLAG_IDLE: called in idle thread context > > 4.2.4 CPU idle notification callback data structures > typedef struct cpu_idle_callback { > int version; > cpu_idle_enter_cbfn idle_enter; > cpu_idle_exit_cbfn idle_exit; > } cpu_idle_callback_t; > At least one of idle_enter and idle_exit is non-NULL. > What is the value of "version" in this structure? > 4.2.5. Register CPU idle notification callback > int cpu_idle_register_callback(uint_t priority, > cpu_idle_callback_t *callbackp, void *arg, void **hdlpp); > This interface registers a callback to be called when CPU idle state > changes. All registered callbacks will be called in priority order > from high to low when CPU enters idle state and will be called in > reverse order when CPU exits idle state. > Argument priority is used to determine the calling order of > registered callbacks. > Argument arg will be passed back to registered callback and how to > use it is determined by callback. > > 4.2.6. Deregister CPU notification callback > int cpu_idle_unregister_callback(uint_t priority, > cpu_idle_callback_t *callbackp, void *arg, void *hdlp); > This interface deregisters a registered callback. > > 4.2.7. Signal entering idle state event > void cpu_idle_enter(cpu_idle_info_t *infop); > This interface notifies idle notification subsystem that a specific > CPU is entering into idle state. > > 4.2.8. Signal exiting idle state event > void cpu_idle_exit(int flags); > This interface notifies idle notification subsystem that a specific > CPU is exiting from idle state. > This seems specific to "idle" notification. Would it be useful to have something that dealt with other kinds of CPU state transitions as well? (C-states, for example?) -- Garrett > 6. Resources and Schedule: > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > From randy.fishel@sun.com Wed Feb 18 12:39:06 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1IKd60m028536 for ; Wed, 18 Feb 2009 12:39:06 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1IKd0nM025818; Wed, 18 Feb 2009 12:39:06 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFA0060R415WC00@brm-avmta-1.central.sun.com>; Wed, 18 Feb 2009 13:39:05 -0700 (MST) Received: from grimmy.sfbay.sun.com ([129.146.108.114]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFA005EU413QE20@brm-avmta-1.central.sun.com>; Wed, 18 Feb 2009 13:39:04 -0700 (MST) Received: from grimmy.eng.sun.com (localhost [127.0.0.1]) by grimmy.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1IKNxRj006300; Wed, 18 Feb 2009 12:23:59 -0800 (PST) Received: from localhost (randyf@localhost) by grimmy.eng.sun.com (8.13.8+Sun/8.13.8/Submit) with ESMTP id n1IKNx41006297; Wed, 18 Feb 2009 12:23:59 -0800 (PST) Date: Wed, 18 Feb 2009 12:23:59 -0800 (PST) From: Randy Fishel Subject: Re: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] In-reply-to: <499C6888.1080802@sun.com> X-X-Sender: randyf@grimmy To: Artem Kachitchkine Cc: PSARC-ext@sun.com, jiang.liu@intel.com, frank.wang@intel.com, tesla-dev@opensolaris.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <499C6888.1080802@sun.com> X-Authentication-warning: grimmy.eng.sun.com: randyf owned process doing -bs User-Agent: Alpine 1.10 (GSO 962 2008-03-14) Status: RO Content-Length: 1739 On Wed, 18 Feb 2009, Artem Kachitchkine wrote: > > > 4.2.5. Register CPU idle notification callback > > int cpu_idle_register_callback(uint_t priority, > > cpu_idle_callback_t *callbackp, void *arg, void **hdlpp); > > This interface registers a callback to be called when CPU idle state > > changes. All registered callbacks will be called in priority order > > from high to low when CPU enters idle state and will be called in > > reverse order when CPU exits idle state. > > Argument priority is used to determine the calling order of > > registered callbacks. > > Argument arg will be passed back to registered callback and how to > > use it is determined by callback. > > What are possible return values and their meaning? > > On architectures that do not implement this functionality (sparc?), will these > functions exist, i.e. will consumers be #ifdef free, and if so, what's the > behavior: fail callback registration, or succeed but never callback. > > -Artem > FWIW, Sparc can use this functionality. Though CPU PM on Sparc is different than on x64, some platforms (especially newer or in development ones) could use and even exploit this mechanism. Individual consumers, though, would likely be platform specific, and wouldn't likely have #ifdefs even if the API were only x64. The project team will hopefully elaborate further, but it would seem to me that the answer would be "succeed, but never callback". The worst case is that there are some internal resources that are never used (i.e. storing callbacks that will never be called), but certainly if a platform that previously could not use the feature finds a way to do so would be able to see results immediately. ---- Randy From Randy.Fishel@sun.com Wed Feb 18 13:08:32 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1IL8WVe029996 for ; Wed, 18 Feb 2009 13:08:32 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1IL8VM1057119; Wed, 18 Feb 2009 14:08:31 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFA00D0F5E6VU00@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Feb 2009 13:08:30 -0800 (PST) Received: from grimmy.sfbay.sun.com ([129.146.108.114]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFA00A8H5E4XS50@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Feb 2009 13:08:28 -0800 (PST) Received: from grimmy.eng.sun.com (localhost [127.0.0.1]) by grimmy.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1IKrPH0006374; Wed, 18 Feb 2009 12:53:25 -0800 (PST) Received: from localhost (randyf@localhost) by grimmy.eng.sun.com (8.13.8+Sun/8.13.8/Submit) with ESMTP id n1IKrPYZ006371; Wed, 18 Feb 2009 12:53:25 -0800 (PST) Date: Wed, 18 Feb 2009 12:53:24 -0800 (PST) From: Randy Fishel Subject: Re: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] In-reply-to: <499C6D90.6020603@sun.com> X-X-Sender: randyf@grimmy To: "Garrett D'Amore" Cc: PSARC-ext@sun.com, jiang.liu@intel.com, frank.wang@intel.com, tesla-dev@opensolaris.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <499C6D90.6020603@sun.com> X-Authentication-warning: grimmy.eng.sun.com: randyf owned process doing -bs User-Agent: Alpine 1.10 (GSO 962 2008-03-14) Status: RO Content-Length: 904 I am going to let the project team respond to the detail questions, but I will respond to questions reguarding the "bigger picture". > > This seems specific to "idle" notification. Would it be useful to have > something that dealt with other kinds of CPU state transitions as well? > (C-states, for example?) > > -- Garrett Predominantly, the issue to external devices is only idle, so that they can take other actions to reduce power. Part of the assumption here is that idle can absorb the extra latency required by the callback and will reduce the impact to performance. Considering that C/T/P-states will likely occur very frequently, having additional notifications could circumvent the value of those state transitions. Evolution of PAD (Power Aware Dispatcher) may change some of these considerations, but for now this is the most we want to open the door. ---- Randy From gdamore@sun.com Wed Feb 18 13:30:15 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1ILUF52000425 for ; Wed, 18 Feb 2009 13:30:15 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1ILU8Js000152; Wed, 18 Feb 2009 13:30:15 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFA00I3L6EE9A00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Feb 2009 13:30:14 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFA009H46EB2V90@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Feb 2009 13:30:11 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1ILUBMS017473; Wed, 18 Feb 2009 13:30:11 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFA00A005XWWS00@fe-sfbay-10.sun.com>; Wed, 18 Feb 2009 13:30:11 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFA00G656E0ERO0@fe-sfbay-10.sun.com>; Wed, 18 Feb 2009 13:30:01 -0800 (PST) Date: Wed, 18 Feb 2009 13:30:00 -0800 From: "Garrett D'Amore" Subject: Re: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] In-reply-to: Sender: Garrett.Damore@sun.com To: Randy Fishel Cc: PSARC-ext@sun.com, jiang.liu@intel.com, frank.wang@intel.com, tesla-dev@opensolaris.org Message-id: <499C7DD8.7000901@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <499C6D90.6020603@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1213 Randy Fishel wrote: > I am going to let the project team respond to the detail questions, > but I will respond to questions reguarding the "bigger picture". > > >> This seems specific to "idle" notification. Would it be useful to have >> something that dealt with other kinds of CPU state transitions as well? >> (C-states, for example?) >> >> -- Garrett >> > > > Predominantly, the issue to external devices is only idle, so that > they can take other actions to reduce power. Part of the assumption > here is that idle can absorb the extra latency required by the > callback and will reduce the impact to performance. Considering that > C/T/P-states will likely occur very frequently, having additional > notifications could circumvent the value of those state transitions. > > Evolution of PAD (Power Aware Dispatcher) may change some of these > considerations, but for now this is the most we want to open the door. > > Fair enough. But, IMO, all the more reason to avoid hard coding a structure and instead use property name/value pairs if at all possible. It sounds like there is potential for significant evolution here in the future. -- Garrett > ---- Randy > From ashok.raj@intel.com Wed Feb 18 14:03:12 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1IM3Cr6001606 for ; Wed, 18 Feb 2009 14:03:12 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1IM366D052305; Wed, 18 Feb 2009 15:03:11 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFA00G0P7XAQM00@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Feb 2009 14:03:10 -0800 (PST) Received: from sca-ea-mail-5.sun.com ([192.18.43.14]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFA00AHG7X8XI90@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Feb 2009 14:03:08 -0800 (PST) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by sca-ea-mail-5.sun.com (8.13.7+Sun/8.12.8) with ESMTP id n1IM37v8016983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=FAIL); Wed, 18 Feb 2009 22:03:08 +0000 (GMT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; Wed, 18 Feb 2009 14:03:07 -0800 Received: from orsmsx604.amr.corp.intel.com ([10.22.226.87]) by azsmga001.ch.intel.com with ESMTP; Wed, 18 Feb 2009 14:03:06 -0800 Received: from orsmsx002.amr.corp.intel.com (10.22.226.105) by orsmsx604.amr.corp.intel.com (10.22.226.87) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 18 Feb 2009 14:03:02 -0800 Received: from orsmsx501.amr.corp.intel.com ([10.22.226.209]) by orsmsx002.amr.corp.intel.com ([10.22.226.105]) with mapi; Wed, 18 Feb 2009 14:03:01 -0800 Date: Wed, 18 Feb 2009 14:04:41 -0800 From: "Raj, Ashok" Subject: RE: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] In-reply-to: <499C7DD8.7000901@sun.com> To: "Garrett D'Amore" , Randy Fishel Cc: "PSARC-ext@sun.com" , "Liu, Jiang" , "tesla-dev@opensolaris.org" , "Wang, Frank" Message-id: <647EFE31A07A4A478691C20DABDFFCB12FF2FEE0@orsmsx501.amr.corp.intel.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] Thread-index: AcmSEER4XJEOWldjTtmZEww64qSAkAAA9B3g acceptlanguage: en-US X-PMX-Version: 5.4.1.325704 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,230,1233561600"; d="scan'208";a="112032773" X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <499C6D90.6020603@sun.com> <499C7DD8.7000901@sun.com> Status: RO Content-Length: 1709 >> >> >> Predominantly, the issue to external devices is only idle, so that >> they can take other actions to reduce power. Part of the assumption >> here is that idle can absorb the extra latency required by the >> callback and will reduce the impact to performance. Considering that >> C/T/P-states will likely occur very frequently, having additional >> notifications could circumvent the value of those state transitions. >> Randy is right. Our initial target is just focused on memory power management. This structure was a lot smaller when we started :-) the other hints were added assuming there might be different things we could do if we know more information.. say when next timeout etc once we have tickless implementation etc. so we can choose different state of power save for memory or other subsystems. >> Evolution of PAD (Power Aware Dispatcher) may change some of these >> considerations, but for now this is the most we want to open the door. >> >> >Fair enough. But, IMO, all the more reason to avoid hard coding a >structure and instead use property name/value pairs if at all possible. >It sounds like there is potential for significant evolution here in the >future. > Thanks Garrett. So you mean how we pass things like ddi_set_prop_valu?? Etc? is there an example you can point to us where a similar callback is structured in a form of name/value pairs as you suggest. Seems like a good approach, just point us in the right direction. As you pointed out the version etc were just for consideration in case we add new/remove old we could keep compatibility.. (but I agree it's a weak approach, generally things would break and you need to support legacy...) Cheers, ashok From gdamore@sun.com Wed Feb 18 14:18:17 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1IMIGDU001961 for ; Wed, 18 Feb 2009 14:18:16 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1IMIAPD027515; Wed, 18 Feb 2009 22:18:14 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFA003038MCBU00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Feb 2009 14:18:12 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFA00MQ58MBXM10@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Feb 2009 14:18:11 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1IMIBTS023427; Wed, 18 Feb 2009 14:18:11 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFA0040077YI900@fe-sfbay-09.sun.com>; Wed, 18 Feb 2009 13:59:16 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFA00GI07Q5EGI0@fe-sfbay-09.sun.com>; Wed, 18 Feb 2009 13:58:58 -0800 (PST) Date: Wed, 18 Feb 2009 14:17:48 -0800 From: "Garrett D'Amore" Subject: Re: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] In-reply-to: <647EFE31A07A4A478691C20DABDFFCB12FF2FEE0@orsmsx501.amr.corp.intel.com> Sender: Garrett.Damore@sun.com To: "Raj, Ashok" Cc: Randy Fishel , "PSARC-ext@sun.com" , "Liu, Jiang" , "tesla-dev@opensolaris.org" , "Wang, Frank" Message-id: <499C890C.3050707@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <499C6D90.6020603@sun.com> <499C7DD8.7000901@sun.com> <647EFE31A07A4A478691C20DABDFFCB12FF2FEE0@orsmsx501.amr.corp.intel.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2292 Raj, Ashok wrote: >>> Predominantly, the issue to external devices is only idle, so that >>> they can take other actions to reduce power. Part of the assumption >>> here is that idle can absorb the extra latency required by the >>> callback and will reduce the impact to performance. Considering that >>> C/T/P-states will likely occur very frequently, having additional >>> notifications could circumvent the value of those state transitions. >>> >>> > > Randy is right. Our initial target is just focused on memory power management. This structure was a lot smaller when we started :-) the other hints were added assuming there might be different things we could do if we know more information.. say when next timeout etc once we have tickless implementation etc. so we can choose different state of power save for memory or other subsystems. > > >>> Evolution of PAD (Power Aware Dispatcher) may change some of these >>> considerations, but for now this is the most we want to open the door. >>> >>> >>> >> Fair enough. But, IMO, all the more reason to avoid hard coding a >> structure and instead use property name/value pairs if at all possible. >> It sounds like there is potential for significant evolution here in the >> future. >> >> > > Thanks Garrett. So you mean how we pass things like ddi_set_prop_valu?? Etc? is there an example you can point to us where a similar callback is structured in a form of name/value pairs as you suggest. > > Seems like a good approach, just point us in the right direction. > > As you pointed out the version etc were just for consideration in case we add new/remove old we could keep compatibility.. (but I agree it's a weak approach, generally things would break and you need to support legacy...) > So, I wasn't requesting anything *specifically* tied to ddi_setprop, etc, A good example of what I'm talking about is how the SCSI capabilities are managed (scsi_ifgetcap()) -- you pass a numeric "name", and get back the value. You can do this in a read-write fashion too. For example, look at how SDcard uses "properties": in usr/src/uts/common/sys/sdcard/sda.h there are the sda_prop_t, and the associated setprop and getprop routines in the sda_ops structure. -- Garrett > Cheers, > ashok > From jiang.liu@intel.com Thu Feb 19 18:17:39 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1K2HcMq004876 for ; Thu, 19 Feb 2009 18:17:38 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1K2HXCG006212; Fri, 20 Feb 2009 02:17:34 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFC00J05ED9SZ00@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Feb 2009 18:17:33 -0800 (PST) Received: from cltea-mail-1.sun.com ([192.18.128.18]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFC00EFRED8H860@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Feb 2009 18:17:33 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by cltea-mail-1.sun.com (8.13.6/8.12.8) with ESMTP id n1K2HVob002008 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Fri, 20 Feb 2009 02:17:31 +0000 (GMT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; Thu, 19 Feb 2009 18:12:36 -0800 Received: from azsmsx602.amr.corp.intel.com ([10.2.121.201]) by orsmga001.jf.intel.com with ESMTP; Thu, 19 Feb 2009 18:17:14 -0800 Received: from pdsmsx602.ccr.corp.intel.com (172.16.12.184) by azsmsx602.amr.corp.intel.com (10.2.121.201) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 19 Feb 2009 19:17:29 -0700 Received: from pdsmsx501.ccr.corp.intel.com ([172.16.12.89]) by pdsmsx602.ccr.corp.intel.com ([172.16.12.184]) with mapi; Fri, 20 Feb 2009 10:17:28 +0800 Date: Fri, 20 Feb 2009 10:17:24 +0800 From: "Liu, Jiang" Subject: RE: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] In-reply-to: <499C890C.3050707@sun.com> To: "Garrett D'Amore" , "Raj, Ashok" Cc: Randy Fishel , "PSARC-ext@sun.com" , "tesla-dev@opensolaris.org" , "Wang, Frank" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] Thread-index: AcmSFst/S+qrdIuYR0SaxJt3OC4ByAA6kLzA acceptlanguage: en-US X-PMX-Version: 5.4.1.325704 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,237,1233561600"; d="scan'208";a="491595727" X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <499C6D90.6020603@sun.com> <499C7DD8.7000901@sun.com> <647EFE31A07A4A478691C20DABDFFCB12FF2FEE0@orsmsx501.amr.corp.intel.com> <499C890C.3050707@sun.com> Status: RO Content-Length: 3193 Hi Garrent, Garrett D'Amore <> wrote: > Raj, Ashok wrote: >>>> Predominantly, the issue to external devices is only idle, so >>>> that they can take other actions to reduce power. Part of the >>>> assumption here is that idle can absorb the extra latency required >>>> by the callback and will reduce the impact to performance. >>>> Considering that C/T/P-states will likely occur very frequently, >>>> having additional notifications could circumvent the value of >>>> those state transitions. >>>> >>>> >> >> Randy is right. Our initial target is just focused on memory power >> management. This structure was a lot smaller when we started :-) the >> other hints were added assuming there might be different things we >> could do if we know more information.. say when next timeout etc >> once we have tickless implementation etc. so we can choose different >> state of power save for memory or other subsystems. >> >> >>>> Evolution of PAD (Power Aware Dispatcher) may change some of >>>> these considerations, but for now this is the most we want to open >>>> the door. >>>> >>>> >>>> >>> Fair enough. But, IMO, all the more reason to avoid hard coding a >>> structure and instead use property name/value pairs if at all >>> possible. It sounds like there is potential for significant >>> evolution here in the future. >>> >>> >> >> Thanks Garrett. So you mean how we pass things like >> ddi_set_prop_valu?? Etc? is there an example you can point to us >> where a similar callback is structured in a form of name/value pairs >> as you suggest. >> >> Seems like a good approach, just point us in the right direction. >> >> As you pointed out the version etc were just for consideration in >> case we add new/remove old we could keep compatibility.. (but I >> agree it's a weak approach, generally things would break and you >> need to support legacy...) >> > > So, I wasn't requesting anything *specifically* tied to ddi_setprop, > etc, > > A good example of what I'm talking about is how the SCSI capabilities > are managed (scsi_ifgetcap()) -- you pass a numeric "name", and get > back the value. You can do this in a read-write fashion too. For > example, look at how SDcard uses "properties": in > usr/src/uts/common/sys/sdcard/sda.h there are the sda_prop_t, and the > associated setprop and getprop routines in the sda_ops structure. > Excellent suggestion to expose data through interface instead of a single data structure. By providing a suite of interface to query value of properties, it would give us following benefits, 1) Easier to deal with compatibility issues. 2) Generate data on demand. CPU idle notification framework doesn't need to generate data for a property if no client requests for it. On the other hand, CPU idle notification framework is performance sensitive and it will give us some performance benefit by directly access data fields in a structure. So we may keep on evolving on this direction and make decision based on more performance data. Should I update the PSARC onepager to integrate this interface? Thanks! > -- Garrett >> Cheers, >> ashok Liu Jiang (Gerry) OpenSolaris, OTC, SSG, Intel From gdamore@sun.com Thu Feb 19 19:41:08 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1K3f7cv008987 for ; Thu, 19 Feb 2009 19:41:07 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1K3f3dP000816; Thu, 19 Feb 2009 20:41:06 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFC00I32I8HXX00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 19 Feb 2009 19:41:05 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFC00DBHI8FI180@nwk-avmta-1.sfbay.Sun.COM>; Thu, 19 Feb 2009 19:41:03 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1K3f3Uf022050; Thu, 19 Feb 2009 19:41:03 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFC00L00I7E3I00@fe-sfbay-10.sun.com>; Thu, 19 Feb 2009 19:41:03 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFC002VWI8EWOC0@fe-sfbay-10.sun.com>; Thu, 19 Feb 2009 19:41:03 -0800 (PST) Date: Thu, 19 Feb 2009 19:41:02 -0800 From: "Garrett D'Amore" Subject: Re: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] In-reply-to: Sender: Garrett.Damore@sun.com To: "Liu, Jiang" Cc: "Raj, Ashok" , Randy Fishel , "PSARC-ext@sun.com" , "tesla-dev@opensolaris.org" , "Wang, Frank" Message-id: <499E264E.5030206@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <499C6D90.6020603@sun.com> <499C7DD8.7000901@sun.com> <647EFE31A07A4A478691C20DABDFFCB12FF2FEE0@orsmsx501.amr.corp.intel.com> <499C890C.3050707@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 3800 Liu, Jiang wrote: > Hi Garrent, > > Garrett D'Amore <> wrote: > >> Raj, Ashok wrote: >> >>>>> Predominantly, the issue to external devices is only idle, so >>>>> that they can take other actions to reduce power. Part of the >>>>> assumption here is that idle can absorb the extra latency required >>>>> by the callback and will reduce the impact to performance. >>>>> Considering that C/T/P-states will likely occur very frequently, >>>>> having additional notifications could circumvent the value of >>>>> those state transitions. >>>>> >>>>> >>>>> >>> Randy is right. Our initial target is just focused on memory power >>> management. This structure was a lot smaller when we started :-) the >>> other hints were added assuming there might be different things we >>> could do if we know more information.. say when next timeout etc >>> once we have tickless implementation etc. so we can choose different >>> state of power save for memory or other subsystems. >>> >>> >>> >>>>> Evolution of PAD (Power Aware Dispatcher) may change some of >>>>> these considerations, but for now this is the most we want to open >>>>> the door. >>>>> >>>>> >>>>> >>>>> >>>> Fair enough. But, IMO, all the more reason to avoid hard coding a >>>> structure and instead use property name/value pairs if at all >>>> possible. It sounds like there is potential for significant >>>> evolution here in the future. >>>> >>>> >>>> >>> Thanks Garrett. So you mean how we pass things like >>> ddi_set_prop_valu?? Etc? is there an example you can point to us >>> where a similar callback is structured in a form of name/value pairs >>> as you suggest. >>> >>> Seems like a good approach, just point us in the right direction. >>> >>> As you pointed out the version etc were just for consideration in >>> case we add new/remove old we could keep compatibility.. (but I >>> agree it's a weak approach, generally things would break and you >>> need to support legacy...) >>> >>> >> So, I wasn't requesting anything *specifically* tied to ddi_setprop, >> etc, >> >> A good example of what I'm talking about is how the SCSI capabilities >> are managed (scsi_ifgetcap()) -- you pass a numeric "name", and get >> back the value. You can do this in a read-write fashion too. For >> example, look at how SDcard uses "properties": in >> usr/src/uts/common/sys/sdcard/sda.h there are the sda_prop_t, and the >> associated setprop and getprop routines in the sda_ops structure. >> >> > > Excellent suggestion to expose data through interface instead of a > single data structure. By providing a suite of interface to query value of > properties, it would give us following benefits, > 1) Easier to deal with compatibility issues. > 2) Generate data on demand. CPU idle notification framework doesn't need > to generate data for a property if no client requests for it. > On the other hand, CPU idle notification framework is performance > sensitive and it will give us some performance benefit by directly access data > fields in a structure. > So we may keep on evolving on this direction and make decision based on > more performance data. > Should I update the PSARC onepager to integrate this interface? > Thanks! > If you're going to change the interface, then please provide an update to the PSARC case materials. If there are compelling performance or consistency reasons where a single structure works better, that's fine. (But if the values don't need to be addressed atomically, and the cost to retrieve them separately is not prohibitive, then it may be better to go this route.) --Garrett > > >> -- Garrett >> >>> Cheers, >>> ashok >>> > > Liu Jiang (Gerry) > OpenSolaris, OTC, SSG, Intel > From jiang.liu@intel.com Fri Feb 20 08:21:35 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1KGLZ4K020771 for ; Fri, 20 Feb 2009 08:21:35 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1KGLWXx023935; Fri, 20 Feb 2009 09:21:34 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFD00JO6HFXE560@nwk-avmta-2.sfbay.sun.com>; Fri, 20 Feb 2009 08:21:33 -0800 (PST) Received: from sca-ea-mail-5.sun.com ([192.18.43.14]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFD00KO9HDV0ZB0@nwk-avmta-2.sfbay.sun.com>; Fri, 20 Feb 2009 08:20:19 -0800 (PST) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by sca-ea-mail-5.sun.com (8.13.7+Sun/8.12.8) with ESMTP id n1KGIccX019448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=FAIL); Fri, 20 Feb 2009 16:18:38 +0000 (GMT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; Fri, 20 Feb 2009 08:18:32 -0800 Received: from azsmsx602.amr.corp.intel.com ([10.2.121.201]) by azsmga001.ch.intel.com with ESMTP; Fri, 20 Feb 2009 08:18:31 -0800 Received: from pdsmsx601.ccr.corp.intel.com (172.16.12.94) by azsmsx602.amr.corp.intel.com (10.2.121.201) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 20 Feb 2009 09:18:31 -0700 Received: from pdsmsx501.ccr.corp.intel.com ([172.16.12.89]) by pdsmsx601.ccr.corp.intel.com ([172.16.12.94]) with mapi; Sat, 21 Feb 2009 00:18:30 +0800 Date: Sat, 21 Feb 2009 00:18:27 +0800 From: "Liu, Jiang" Subject: RE: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] In-reply-to: <499C6888.1080802@sun.com> To: "Artem.Kachitchkin@Sun.COM" , Randy Fishel Cc: "PSARC-ext@Sun.COM" , "Wang, Frank" , "tesla-dev@opensolaris.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] Thread-index: AcmSA3lJVUAvfUfbQ2aqTfsIE3NeewBcnMIw acceptlanguage: en-US X-PMX-Version: 5.4.1.325704 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,242,1233561600"; d="scan'208";a="112742320" X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <499C6888.1080802@sun.com> Status: RO Content-Length: 1291 Hi Artem, Please refer to comments below, thanks! Artem.Kachitchkin@Sun.COM wrote: >> 4.2.5. Register CPU idle notification callback >> int cpu_idle_register_callback(uint_t priority, >> cpu_idle_callback_t *callbackp, void *arg, void **hdlpp); >> This interface registers a callback to be called when CPU idle state >> changes. All registered callbacks will be called in priority order >> from high to low when CPU enters idle state and will be called in >> reverse order when CPU exits idle state. >> Argument priority is used to determine the calling order of >> registered callbacks. Argument arg will be passed back to >> registered callback and how to use it is determined by callback. > > What are possible return values and their meaning? The return value is zero on success or error number on failure. > > On architectures that do not implement this functionality (sparc?), > will these functions exist, i.e. will consumers be #ifdef free, and > if so, what's the behavior: fail callback registration, or succeed > but never callback. On platform which doesn't support such a mechanism, the registration will succeed but the registered callbacks won't be called. > > -Artem Liu Jiang (Gerry) OpenSolaris, OTC, SSG, Intel From jiang.liu@intel.com Wed Feb 25 08:35:12 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1PGZAVg006825 for ; Wed, 25 Feb 2009 08:35:11 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n1PGYp0i028400; Thu, 26 Feb 2009 00:35:06 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFM00I39REFLN00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Feb 2009 08:35:03 -0800 (PST) Received: from cltea-mail-1.sun.com ([192.18.128.18]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFM00A43REA7CD0@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Feb 2009 08:34:59 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by cltea-mail-1.sun.com (8.13.6/8.12.8) with ESMTP id n1PGYuNt026265 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Wed, 25 Feb 2009 16:34:57 +0000 (GMT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; Wed, 25 Feb 2009 08:27:42 -0800 Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81]) by orsmga002.jf.intel.com with ESMTP; Wed, 25 Feb 2009 08:43:38 -0800 Received: from pgsmsx601.gar.corp.intel.com (10.221.43.69) by pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 26 Feb 2009 00:34:43 +0800 Received: from pdsmsx602.ccr.corp.intel.com (172.16.12.184) by pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 26 Feb 2009 00:34:43 +0800 Received: from pdsmsx501.ccr.corp.intel.com ([172.16.12.89]) by pdsmsx602.ccr.corp.intel.com ([172.16.12.184]) with mapi; Thu, 26 Feb 2009 00:34:42 +0800 Date: Thu, 26 Feb 2009 00:34:39 +0800 From: "Liu, Jiang" Subject: RE: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] In-reply-to: <499E264E.5030206@sun.com> To: "Garrett D'Amore" Cc: "Raj, Ashok" , Randy Fishel , "PSARC-ext@sun.com" , "tesla-dev@opensolaris.org" , "Wang, Frank" Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_16FJef+O3iIa56XuMfJjBA)" Content-language: en-US Accept-Language: en-US Thread-topic: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] Thread-index: AcmTDRKTvOQtU5MdRTWZwLblgonyQAEWKaAA acceptlanguage: en-US X-PMX-Version: 5.4.1.325704 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,266,1233561600"; d="diff'?txt'?scan'208";a="389695645" X-MS-Has-Attach: yes X-MS-TNEF-Correlator: References: <499C6D90.6020603@sun.com> <499C7DD8.7000901@sun.com> <647EFE31A07A4A478691C20DABDFFCB12FF2FEE0@orsmsx501.amr.corp.intel.com> <499C890C.3050707@sun.com> <499E264E.5030206@sun.com> Status: RO Content-Length: 21808 --Boundary_(ID_16FJef+O3iIa56XuMfJjBA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Randy, Garrent and Artem, I have made some changes/enhancements to CPU idle notification PSARC onepager according to kindly feedbacks from PSARC/Tesla review. Could you please help to review it again? The attachments is the latest PSARC onepager and a diff file with previous version. The main changes include: 1) Add more comments to function parameters and return value. 2) Provide a suite of interfaces to access CPU idle properties instead of directly accessing data structure fields in previous version. 3) Add constraints to call some interfaces. Thanks for your kindly help! Liu Jiang (Gerry) OpenSolaris, OTC, SSG, Intel Garrett D'Amore <> wrote: > Liu, Jiang wrote: >> Hi Garrent, >> >> Garrett D'Amore <> wrote: >> >>> Raj, Ashok wrote: >>> >>>>>> Predominantly, the issue to external devices is only idle, so >>>>>> that they can take other actions to reduce power. Part of the >>>>>> assumption here is that idle can absorb the extra latency >>>>>> required by the callback and will reduce the impact to >>>>>> performance. Considering that C/T/P-states will likely occur >>>>>> very frequently, having additional notifications could >>>>>> circumvent the value of those state transitions. >>>>>> >>>>>> >>>>>> >>>> Randy is right. Our initial target is just focused on memory power >>>> management. This structure was a lot smaller when we started :-) >>>> the other hints were added assuming there might be different >>>> things we could do if we know more information.. say when next >>>> timeout etc once we have tickless implementation etc. so we can >>>> choose different state of power save for memory or other >>>> subsystems. >>>> >>>> >>>> >>>>>> Evolution of PAD (Power Aware Dispatcher) may change some of >>>>>> these considerations, but for now this is the most we want to >>>>>> open the door. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Fair enough. But, IMO, all the more reason to avoid hard coding a >>>>> structure and instead use property name/value pairs if at all >>>>> possible. It sounds like there is potential for significant >>>>> evolution here in the future. >>>>> >>>>> >>>>> >>>> Thanks Garrett. So you mean how we pass things like >>>> ddi_set_prop_valu?? Etc? is there an example you can point to us >>>> where a similar callback is structured in a form of name/value >>>> pairs as you suggest. >>>> >>>> Seems like a good approach, just point us in the right direction. >>>> >>>> As you pointed out the version etc were just for consideration in >>>> case we add new/remove old we could keep compatibility.. (but I >>>> agree it's a weak approach, generally things would break and you >>>> need to support legacy...) >>>> >>>> >>> So, I wasn't requesting anything *specifically* tied to >>> ddi_setprop, etc, >>> >>> A good example of what I'm talking about is how the SCSI >>> capabilities are managed (scsi_ifgetcap()) -- you pass a numeric >>> "name", and get back the value. You can do this in a read-write >>> fashion too. For example, look at how SDcard uses "properties": in >>> usr/src/uts/common/sys/sdcard/sda.h there are the sda_prop_t, and >>> the associated setprop and getprop routines in the sda_ops >>> structure. >>> >>> >> >> Excellent suggestion to expose data through interface instead of a >> single data structure. By providing a suite of interface to query >> value of properties, it would give us following benefits, >> 1) Easier to deal with compatibility issues. >> 2) Generate data on demand. CPU idle notification framework doesn't >> need >> to generate data for a property if no client requests for it. >> On the other hand, CPU idle notification framework is performance >> sensitive and it will give us some performance benefit by directly >> access data fields in a structure. So we may keep on evolving on >> this direction and make decision based on >> more performance data. >> Should I update the PSARC onepager to integrate this interface? >> Thanks! >> > > If you're going to change the interface, then please provide an update > to the PSARC case materials. > > If there are compelling performance or consistency reasons where a > single structure works better, that's fine. (But if the values don't > need to be addressed atomically, and the cost to retrieve them > separately is not prohibitive, then it may be better to go this > route.) > > --Garrett > >> >> >>> -- Garrett >>> >>>> Cheers, >>>> ashok >>>> >> >> Liu Jiang (Gerry) >> OpenSolaris, OTC, SSG, Intel Liu Jiang (Gerry) OpenSolaris, OTC, SSG, Intel --Boundary_(ID_16FJef+O3iIa56XuMfJjBA) Content-type: application/octet-stream; name=onepager_v4_v6.diff Content-transfer-encoding: base64 Content-disposition: attachment; filename=onepager_v4_v6.diff; size=6900; creation-date="Tue, 24 Feb 2009 10:12:41 GMT"; modification-date="Tue, 24 Feb 2009 10:11:18 GMT" Content-description: onepager_v4_v6.diff MTFjMTEKPCAJTm92ZW1iZXIgMTYsIDIwMDgKLS0tCj4gCUZlYiAyMSwgMjAwOQoyNyw0M2MyNywz Ngo8ICAgICA0LjIuMSBDUFUgaWRsZSBub3RpZmljYXRpb24gaW5mb3JtYXRpb24gZGF0YSBzdHJ1 Y3R1cmUKPCAJdHlwZWRlZiBzdHJ1Y3QgY3B1X2lkbGVfaW5mbyB7CjwgCQlpbnQJIGNpX2ZsYWdz Owo8IAkJaW50CSBjaV9pbnRyX2NvdW50OwkgICAvKiBJbnRlcnJ1cHQgY291bnQuICovCjwgCQlp bnQJIGNpX2lkbGVfc3RhdGU7CSAgIC8qIElkbGUgc3RhdGUgdG8gZW50ZXIuICovCjwgCQlocnRp bWVfdCBjaV9pZGxlX2xhdGVuY3k7ICAvKiBJZGxlIHJvdW5kIHRyaXAgbGF0ZW5jeS4gKi8KPCAJ CWhydGltZV90IGNpX21heF9pZGxlX3RpbWU7IC8qIFByZWRpY3RlZCBtYXggaWRsZSB0aW1lLiAq Lwo8IAkJaHJ0aW1lX3QgY2lfbGFzdF9pZGxlX3RpbWU7LyogTGFzdCBpZGxlIHBlcmlvZC4gKi8K PCAJCWhydGltZV90IGNpX2xhc3RfYnVzeV90aW1lOy8qIExhc3QgYnVzeSBwZXJpb2QuICovCjwg CX0gY3B1X2lkbGVfaW5mb190Owo8IAlUaGlzIHN0cnVjdHVyZSBpcyB1c2VkIHRvIHBhc3MgQ1BV IGlkbGUgaW5mb3JtYXRpb24gdG8gY2FsbGJhY2tzLgo8IAlJdCBjb3VsZCBiZSBleHRlbmRlZCB0 byBzdXBwb3J0IGFyY2hpdGVjdHVyZS9wbGF0Zm9ybSBzcGVjaWZpYwo8IAlpbmZvcm1hdGlvbiBp biBmdXR1cmUuCjwgCVZhbGlkIGZsYWdzIGZvciBjcHVfaWRsZV9pbmZvX3Q6CjwgCSAgICBDUFVf SURMRV9DSV9GTEFHX0lETEVfU1RBVEU6IGZpZWxkIGNpX2lkbGVfc3RhdGUgaXMgdmFsaWQuCjwg CSAgICBDUFVfSURMRV9DSV9GTEFHX0lETEVfTEFURU5DWTogZmllbGQgY2lfaWRsZV9sYXRlbmN5 IGlzIHZhbGlkLgo8IAkgICAgQ1BVX0lETEVfQ0JfRkxBR19NQVhfSURMRV9USU1FOiBmaWVsZCBj aV9tYXhfaWRsZV90aW1lIGlzIHZhbGlkLgotLS0KPiAgICAgNC4yLjEgQ1BVIGlkbGUgbm90aWZp Y2F0aW9uIGRhdGEgc3RydWN0dXJlCj4gCXR5cGVkZWYgdm9pZCAqCWNwdV9pZGxlX2NhbGxiYWNr X2hhbmRsZV90Owo+IAl0eXBlZGVmIHZvaWQgKgljcHVfaWRsZV9jYWxsYmFja19jb250ZXh0X3Q7 Cj4gCXR5cGVkZWYgdm9pZCAqCWNwdV9pZGxlX3Byb3BfaGFuZGxlX3Q7Cj4gCXR5cGVkZWYgdW5p b24gY3B1X2lkbGVfcHJvcF92YWx1ZSB7Cj4gCQlpbnRwdHJfdAljaXB2X2ludHB0cjsKPiAJCXVp bnQzMl90CWNpcHZfdWludDMyOwo+IAkJdWludDY0X3QJY2lwdl91aW50NjQ7Cj4gCQlocnRpbWVf dAljaXB2X2hydGltZTsKPiAJfSBjcHVfaWRsZV9wcm9wX3ZhbHVlX3Q7CjQ3YzQwCjwgCSAgICBj cHVfaWRsZV9pbmZvX3QgKmluZm9wKTsKLS0tCj4gCSAgICBjcHVfaWRsZV9jYWxsYmFja19jb250 ZXh0X3QgKmN0eHApOwo0OSw1MWM0Miw0NQo8IAl3aGljaCBhcHBsaWVzIHRvIGlkbGUgdGhyZWFk IGJlY3Vhc2UgaXQgd2lsbCBiZSBjYWxsZWQgaW4gaWRsZSAKPCAJdGhyZWFkIGNvbnRleHQuCjwg CUFyZ3VtZW50IGFyZyBpcyB0aGUgcGFyYW1ldGVyIHBhc3NlZCBpbiB3aGVuIHJlZ2lzdGVyaW5n IGNhbGxiYWNrLgotLS0KPiAJd2hpY2ggYXBwbGllcyB0byBpZGxlIHRocmVhZCBiZWNhdXNlIGl0 IHdpbGwgYmUgY2FsbGVkIGluIGlkbGUgCj4gCXRocmVhZCBjb250ZXh0LiBBbmQgaXQgbWF5IGJl IGNhbGxlZCB3aXRoIGludGVycnVwdCBlbmFibGVkL2Rpc2FibGVkLgo+IAlhcmcgaXMgdGhlIHBh cmFtZXRlciBwYXNzZWQgaW4gd2hlbiByZWdpc3RlcmluZyBjYWxsYmFjay4KPiAJY3R4cCBpcyBh biBvcGFxdWUgcGFyYW1ldGVyIHdoaWNoIHdpbGwgYmUgdXNlZCB0byByZXRyaWV2ZSBwcm9wZXJ0 eS4KNTRjNDgsNDkKPCAJdHlwZWRlZiB2b2lkICgqY3B1X2lkbGVfZXhpdF9jYmZuKSh2b2lkICph cmcsIGludCBmbGFncyk7Ci0tLQo+IAl0eXBlZGVmIHZvaWQgKCpjcHVfaWRsZV9leGl0X2NiZm4p KHZvaWQgKmFyZywgCj4gCSAgICBjcHVfaWRsZV9jYWxsYmFja19jb250ZXh0X3QgKmN0eHAsIGlu dCBmbGFncyk7CjU5YzU0LDU1CjwgCVZhbGlkIGZsYWdzIGZvciBleGl0aW5nIGlkbGUgc3RhdGUg bm90aWZpY2F0aW9uIGNhbGxiYWNrOgotLS0KPiAJY3R4cCBpcyBhbiBvcGFxdWUgcGFyYW1ldGVy IHdoaWNoIHdpbGwgYmUgdXNlZCB0byByZXRyaWV2ZSBwcm9wZXJ0eS4KPiAJZmxhZ3MgZm9yIGV4 aXRpbmcgaWRsZSBzdGF0ZSBub3RpZmljYXRpb24gY2FsbGJhY2s6CjY5YTY2LDY3Cj4gCUZpZWxk IHZlcnNpb24gd2lsbCBiZSB1c2VkIHRvIG1hdGNoIGNwdV9pZGxlX2NhbGxiYWNrX3Qgc3RydWN0 dXJlIGFuZCAKPiAJQ1BVIGlkbGUgbm90aWZpY2F0aW9uIGZyYW1ld29yay4KNzNjNzEsNzIKPCAJ ICAgIGNwdV9pZGxlX2NhbGxiYWNrX3QgKmNhbGxiYWNrcCwgdm9pZCAqYXJnLCB2b2lkICoqaGRs cHApOwotLS0KPiAJICAgIGNwdV9pZGxlX2NhbGxiYWNrX3QgKmNhbGxiYWNrcCwgdm9pZCAqYXJn LAo+IAkgICAgY3B1X2lkbGVfY2FsbGJhY2tfaGFuZGxlX3QgKmhkbHApOwo3Nyw4MWM3Niw4NQo8 IAlyZXZlcnNlIG9yZGVyIHdoZW4gQ1BVIGV4aXRzIGlkbGUgc3RhdGUuCjwgCUFyZ3VtZW50IHBy aW9yaXR5IGlzIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBjYWxsaW5nIG9yZGVyIG9mCjwgCXJlZ2lz dGVyZWQgY2FsbGJhY2tzLgo8IAlBcmd1bWVudCBhcmcgd2lsbCBiZSBwYXNzZWQgYmFjayB0byBy ZWdpc3RlcmVkIGNhbGxiYWNrIGFuZCBob3cgdG8KPCAJdXNlIGl0IGlzIGRldGVybWluZWQgYnkg Y2FsbGJhY2suCi0tLQo+IAlyZXZlcnNlIG9yZGVyIHdoZW4gQ1BVIGV4aXRzIGlkbGUgc3RhdGUu IElmIENQVSBpcyBwcmVkaWN0ZWQgdG8gc2xlZXAKPiAJZm9yIGEgc2hvcnQgdGltZSBvciBiZSB1 bmRlciBoZWF2eSBsb2FkLCBmcmFtZXdvcmsgbWF5IHNraXAgY2FsbGluZyAKPiAJcmVnaXN0ZXJl ZCBjYWxsYmFja3Mgd2hlbiBlbnRlcmluZy9leGl0aW5nIGlkbGUgc3RhdGUgdG8gYXZvaWQgCj4g CW92ZXJoZWFkIGFuZCByZWR1Y2UgcGVyZm9ybWFuY2UgcGVuYWx0eS4gVGhpcyBpbnRlcmZhY2Ug c2hvdWxkbid0IGJlIAo+IAljYWxsZWQgZnJvbSBjYWxsYmFjayBoYW5kbGVycy4KPiAJcHJpb3Jp dHkgaXMgdXNlZCB0byBkZXRlcm1pbmUgY2FsbGluZyBvcmRlciBvZiByZWdpc3RlcmVkIGNhbGxi YWNrcy4KPiAJYXJnIHdpbGwgYmUgcGFzc2VkIGJhY2sgdG8gcmVnaXN0ZXJlZCBjYWxsYmFjayBh bmQgaG93IHRvIHVzZSBpdCBpcwo+IAlkZXRlcm1pbmVkIGJ5IGNhbGxiYWNrLgo+IAloZGxwIGlz IHVzZWQgdG8gc3RvcmVkIGNyZWF0ZWQgaGFuZGxlIG9uIHN1Y2Nlc3MuCj4gCUl0IHJldHVybnMg emVybyBvbiBzdWNjZXNzIGFuZCBlcnJvciBudW1iZXIgb24gZmFpbHVyZS4KODQsODZjODgsOTEK PCAJaW50IGNwdV9pZGxlX3VucmVnaXN0ZXJfY2FsbGJhY2sodWludF90IHByaW9yaXR5LAo8IAkg ICAgY3B1X2lkbGVfY2FsbGJhY2tfdCAqY2FsbGJhY2twLCB2b2lkICphcmcsIHZvaWQgKmhkbHAp Owo8IAlUaGlzIGludGVyZmFjZSBkZXJlZ2lzdGVycyBhIHJlZ2lzdGVyZWQgY2FsbGJhY2suCi0t LQo+IAlpbnQgY3B1X2lkbGVfdW5yZWdpc3Rlcl9jYWxsYmFjayhjcHVfaWRsZV9jYWxsYmFja19o YW5kbGVfdCBoZGxwKTsKPiAJVGhpcyBpbnRlcmZhY2UgZGVyZWdpc3RlcnMgYSByZWdpc3RlcmVk IGNhbGxiYWNrLiBJdCBzaG91bGRuJ3QgYmUgCj4gCWNhbGxlZCBmcm9tIGNhbGxiYWNrIGhhbmRs ZXIuCj4gCUl0IHJldHVybnMgemVybyBvbiBzdWNjZXNzIGFuZCBlcnJvciBudW1iZXIgb24gZmFp bHVyZS4KODksOTBjOTQsOTUKPCAJdm9pZCBjcHVfaWRsZV9lbnRlcihjcHVfaWRsZV9pbmZvX3Qg KmluZm9wKTsKPCAJVGhpcyBpbnRlcmZhY2Ugbm90aWZpZXMgaWRsZSBub3RpZmljYXRpb24gc3Vi c3lzdGVtIHRoYXQgYSBzcGVjaWZpYwotLS0KPiAJdm9pZCBjcHVfaWRsZV9lbnRlcihpbnQgc3Rh dGUpOwo+IAlUaGlzIGludGVyZmFjZSBub3RpZmllcyBDUFUgaWRsZSBub3RpZmljYXRpb24gc3Vi c3lzdGVtIHRoYXQgYSBzcGVjaWZpYwo5MWE5Nwo+IAlzdGF0ZSBpcyBpZGxlIHN0YXRlIENQVSBp cyBnb2luZyB0byBlbnRlci4KOTZhMTAzLDEwNQo+IAlmbGFncyBmb3IgZXhpdGluZyBpZGxlIHN0 YXRlOgo+IAkgICAgQ1BVX0lETEVfQ0JfRkxBR19JTlRSOiBjYWxsZWQgaW4gaW50ZXJydXB0IGNv bnRleHQKPiAJICAgIENQVV9JRExFX0NCX0ZMQUdfSURMRTogY2FsbGVkIGluIGlkbGUgdGhyZWFk IGNvbnRleHQKOTdhMTA3LDE1Nwo+ICAgICA0LjIuOS4gR2V0IGlkbGUgY2FsbGJhY2sgY29udGV4 dCBmb3IgY2FsbGluZyBDUFUKPiAJY3B1X2lkbGVfY2FsbGJhY2tfY29udGV4dF90IGNwdV9pZGxl X2dldF9jb250ZXh0KHZvaWQpOwo+IAo+ICAgICA0LjIuMTAuIENyZWF0ZSBwcm9wZXJ0eSBoYW5k bGUKPiAJaW50IGNwdV9pZGxlX3Byb3BfY3JlYXRlX2hhbmRsZShjb25zdCBjaGFyICpwcm9wbmFt ZSwKPiAJICAgIGNwdV9pZGxlX3Byb3BfaGFuZGxlX3QgKnByb3BoZGwpOwo+IAlUaGlzIGZ1bmN0 aW9uIGNyZWF0ZXMgYSBoYW5kbGUgZm9yIHNwZWNpZmljIHByb3BlcnR5IGlmIGl0J3Mgc3VwcG9y dGVkLgo+IAlJdCByZXR1cm5zIHplcm8gb24gc3VjY2VzcyBvciBlcnJvciBjb2RlIG9uIGZhaWx1 cmUuCj4gCj4gICAgIDQuMi4xMS4gU2V0IHByb3BlcnR5IHZhbHVlCj4gCXZvaWQgY3B1X2lkbGVf cHJvcGVydHlfc2V0KGNwdV9pZGxlX3Byb3BfaGFuZGxlX3QgcHJvcGhkbCwKPiAJICAgIGNwdV9p ZGxlX2NhbGxiYWNrX2NvbnRleHRfdCBjdHgsIGNwdV9pZGxlX3Byb3BfdmFsdWVfdCB2YWwpOwo+ IAlUaGlzIGZ1bmN0aW9uIGlzIHVzZWQgYnkgcHJvcGVydHkgcHJvdmlkZXIgdG8gc2V0IHZhbHVl IGZvciBwcm9wZXJ0eS4KPiAKPiAgICAgNC4yLjEyLiBHZXQgcHJvcGVydHkgdmFsdWUKPiAJaW50 IGNwdV9pZGxlX3Byb3BlcnR5X2dldChjcHVfaWRsZV9wcm9wX2hhbmRsZV90IHByb3BoZGwsCj4g CSAgICBjcHVfaWRsZV9jYWxsYmFja19jb250ZXh0X3QgY3R4LCBjcHVfaWRsZV9wcm9wX3ZhbHVl X3QgKnZhbHApOwo+IAlUaGUgZnVuY3Rpb24gdHJpZXMgdG8gZ2V0IHZhbHVlIG9mIGEgcHJvcGVy dHksIGl0IG1heSBmYWlsIGluIGNhc2UgdGhhdAo+IAl0aGUgcHJvcGVydHkgZG9lc24ndCBzdXBw b3J0IGZhc3QgYWNjZXNzLgo+IAlJdCByZXR1cm4gemVybyBvbiBzdWNjZXNzIGFuZCBlcnJvciBu dW1iZXIgb24gZmFpbHVyZS4KPiAKPiAJdWludDMyX3QgY3B1X2lkbGVfcHJvcF9nZXRfdWludDMy KGNwdV9pZGxlX3Byb3BfaGFuZGxlX3QgcHJvcGhkbCwKPiAJICAgIGNwdV9pZGxlX2NhbGxiYWNr X2NvbnRleHRfdCBjdHgpOwo+IAl1aW50NjRfdCBjcHVfaWRsZV9wcm9wX2dldF91aW50NjQoY3B1 X2lkbGVfcHJvcF9oYW5kbGVfdCBwcm9waGRsLAo+IAkgICAgY3B1X2lkbGVfY2FsbGJhY2tfY29u dGV4dF90IGN0eCk7Cj4gCWludHB0cl90IGNwdV9pZGxlX3Byb3BfZ2V0X2ludHB0cihjcHVfaWRs ZV9wcm9wX2hhbmRsZV90IHByb3BoZGwsCj4gCSAgICBjcHVfaWRsZV9jYWxsYmFja19jb250ZXh0 X3QgY3R4KTsKPiAJaHJ0aW1lX3QgY3B1X2lkbGVfcHJvcF9nZXRfaHJ0aW1lKGNwdV9pZGxlX3By b3BfaGFuZGxlX3QgcHJvcGhkbCwKPiAJICAgIGNwdV9pZGxlX2NhbGxiYWNrX2NvbnRleHRfdCBj dHgpOwo+IAlUaGlzIHN1aXRlIG9mIGZ1bmN0aW9ucyByZXRyaWV2ZSB2YWx1ZSBvZiBwcm9wZXJ0 eSB3aGljaCBzdXBwb3J0cyAKPiAJZmFzdCBhY2Nlc3MuCj4gCj4gICAgIDQuMi4xMy4gU3VwcG9y dGVkIHByb3BlcnRpZXMKPiAJQWxsIHByb3BlcnRpZXMgd2l0aG91dCBzcGVjaWFsIG5vdGVzIGFy ZSBwZXIgbG9naWNhbCBDUFUgc3RhdGlzdGljcy4KPiAKPiAJVGhlIGZyYW1ld29yayBzdXBwb3J0 cyBmb2xsb3dpbmcgcHJvcGVydGllcyBieSBkZWZhdWx0Lgo+IAlfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gCXwg UHJvcGVydHkgTmFtZSAgIHwgRGF0YSBUeXBlIHwgRmFzdCAgIHwgRGVjcmlwdGlvbiAgICAgICAg ICAgICAgICAgICB8Cj4gCXxfX19fX19fX19fX19fX19fX3xfX19fX19fX19fX3xfQWNjZXNzX3xf X19fX19fX19fX19fX19fX19fX19fX19fX19fX198Cj4gCXwgaWRsZS1zdGF0ZQkgIHwgaW50CSAg ICAgIHwgWWVzICAgIHwgQ1BVIElkbGUgc3RhdGUgdG8gZW50ZXIgICAgICB8Cj4gCXwgaWRsZS1l bnRlci10cwkgIHwgaHJ0aW1lX3QgIHwgWWVzICAgIHwgVGltZXN0YW1wIGZvciBlbnRlcmluZyBp ZGxlICB8Cj4gCXwgaWRsZS1leGl0LXRzCSAgfCBocnRpbWVfdCAgfCBZZXMgICAgfCBUaW1lc3Rh bXAgZm9yIGV4aXRpbmcgaWRsZSAgIHwKPiAJfCBsYXN0LWlkbGUtdGltZSAgfCBocnRpbWVfdCAg fCBZZXMgICAgfCBMYXN0IGlkbGUgcGVyaW9kICAgICAgICAgICAgIHwKPiAJfCBsYXN0LWJ1c3kt dGltZSAgfCBocnRpbWVfdCAgfCBZZXMgICAgfCBMYXN0IGJ1c3kgcGVyaW9kICAgICAgICAgICAg IHwKPiAJfCBpbnRlcnJ1cHQtY291bnQgfCB1aW50NjRfdCAgfCBZZXMgICAgfCBJbnRlcnJ1cHQg Y291bnQgaW4gbGFzdCBidXN5IHwKPiAJfF9fX19fX19fX19fX19fX19ffF9fX19fX19fX19ffF9f X19fX19ffCBwZXJpb2RfX19fX19fX19fX19fX19fX19fX19fX3wKPiAKPiAJT3RoZXIgcHJvcGVy dHkgcHJvdmlkZXJzIG1heSBhZGQgbmV3IHByb3BlcnRpZXMgdG8gZnJhbWV3b3JrIGluIGZ1dHVy ZS4KPiAJRm9yIGV4YW1wbGUsIENQVSBwb3dlciBtYW5hZ2VtZW50IGRyaXZlciBtYXkgc3VwcG9y dCAiaWRsZS1sYXRlbmN5IiwKPiAJIm1heC1pZGxlLXRpbWUiIGV0Yy4KPiAKMTAzYzE2Mwo8ICAg ICA2LjYuIEFSQyBFeHBvc3VyZTogb3BlbgotLS0KPiAgICAgNi42LiBBUkMgRXhwb3N1cmU6IG9w ZW4K --Boundary_(ID_16FJef+O3iIa56XuMfJjBA) Content-type: text/plain; name=onepager_v6.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=onepager_v6.txt; size=7236; creation-date="Tue, 24 Feb 2009 09:59:03 GMT"; modification-date="Tue, 24 Feb 2009 10:11:08 GMT" Content-description: onepager_v6.txt Template Version: @(#)onepager.txt 1.35 07/11/07 SMI 1. Introduction 1.1. Project/Component Working Name: CPU idle notification interface 1.2. Name of Document Author/Supplier: Author: Gerry Liu 1.3. Date of This Document: Feb 21, 2009 4. Technical Description: 4.1. Problem A CPU idle notification mechanism is needed to signal other components which are interested in the CPU idle state change events when CPU enters/exits idle state. This mechanism could be used by following components: A) Memory power saving driver B) Lazy TLB flush on x86 system C) CPU power management framework 4.2. Proposal We propose to add following data structures/interfaces to OpenSolaris kernel. 4.2.1 CPU idle notification data structure typedef void * cpu_idle_callback_handle_t; typedef void * cpu_idle_callback_context_t; typedef void * cpu_idle_prop_handle_t; typedef union cpu_idle_prop_value { intptr_t cipv_intptr; uint32_t cipv_uint32; uint64_t cipv_uint64; hrtime_t cipv_hrtime; } cpu_idle_prop_value_t; 4.2.2 Prototype of entering idle state notification callback typedef void (*cpu_idle_enter_cbfn)(void *arg, cpu_idle_callback_context_t *ctxp); Entering idle state notification callback must obey all constraints which applies to idle thread because it will be called in idle thread context. And it may be called with interrupt enabled/disabled. arg is the parameter passed in when registering callback. ctxp is an opaque parameter which will be used to retrieve property. 4.2.3 Prototype of exiting idle state notification callback typedef void (*cpu_idle_exit_cbfn)(void *arg, cpu_idle_callback_context_t *ctxp, int flags); Exiting idle state notification callback will be called in idle thread context or interrupt context. There are flags to distinguish the calling contexts. arg is the parameter passed in when registering callback. ctxp is an opaque parameter which will be used to retrieve property. flags for exiting idle state notification callback: CPU_IDLE_CB_FLAG_INTR: called in interrupt context CPU_IDLE_CB_FLAG_IDLE: called in idle thread context 4.2.4 CPU idle notification callback data structures typedef struct cpu_idle_callback { int version; cpu_idle_enter_cbfn idle_enter; cpu_idle_exit_cbfn idle_exit; } cpu_idle_callback_t; At least one of idle_enter and idle_exit is non-NULL. Field version will be used to match cpu_idle_callback_t structure and CPU idle notification framework. 4.2.5. Register CPU idle notification callback int cpu_idle_register_callback(uint_t priority, cpu_idle_callback_t *callbackp, void *arg, cpu_idle_callback_handle_t *hdlp); This interface registers a callback to be called when CPU idle state changes. All registered callbacks will be called in priority order from high to low when CPU enters idle state and will be called in reverse order when CPU exits idle state. If CPU is predicted to sleep for a short time or be under heavy load, framework may skip calling registered callbacks when entering/exiting idle state to avoid overhead and reduce performance penalty. This interface shouldn't be called from callback handlers. priority is used to determine calling order of registered callbacks. arg will be passed back to registered callback and how to use it is determined by callback. hdlp is used to stored created handle on success. It returns zero on success and error number on failure. 4.2.6. Deregister CPU notification callback int cpu_idle_unregister_callback(cpu_idle_callback_handle_t hdlp); This interface deregisters a registered callback. It shouldn't be called from callback handler. It returns zero on success and error number on failure. 4.2.7. Signal entering idle state event void cpu_idle_enter(int state); This interface notifies CPU idle notification subsystem that a specific CPU is entering into idle state. state is idle state CPU is going to enter. 4.2.8. Signal exiting idle state event void cpu_idle_exit(int flags); This interface notifies idle notification subsystem that a specific CPU is exiting from idle state. flags for exiting idle state: CPU_IDLE_CB_FLAG_INTR: called in interrupt context CPU_IDLE_CB_FLAG_IDLE: called in idle thread context 4.2.9. Get idle callback context for calling CPU cpu_idle_callback_context_t cpu_idle_get_context(void); 4.2.10. Create property handle int cpu_idle_prop_create_handle(const char *propname, cpu_idle_prop_handle_t *prophdl); This function creates a handle for specific property if it's supported. It returns zero on success or error code on failure. 4.2.11. Set property value void cpu_idle_property_set(cpu_idle_prop_handle_t prophdl, cpu_idle_callback_context_t ctx, cpu_idle_prop_value_t val); This function is used by property provider to set value for property. 4.2.12. Get property value int cpu_idle_property_get(cpu_idle_prop_handle_t prophdl, cpu_idle_callback_context_t ctx, cpu_idle_prop_value_t *valp); The function tries to get value of a property, it may fail in case that the property doesn't support fast access. It return zero on success and error number on failure. uint32_t cpu_idle_prop_get_uint32(cpu_idle_prop_handle_t prophdl, cpu_idle_callback_context_t ctx); uint64_t cpu_idle_prop_get_uint64(cpu_idle_prop_handle_t prophdl, cpu_idle_callback_context_t ctx); intptr_t cpu_idle_prop_get_intptr(cpu_idle_prop_handle_t prophdl, cpu_idle_callback_context_t ctx); hrtime_t cpu_idle_prop_get_hrtime(cpu_idle_prop_handle_t prophdl, cpu_idle_callback_context_t ctx); This suite of functions retrieve value of property which supports fast access. 4.2.13. Supported properties All properties without special notes are per logical CPU statistics. The framework supports following properties by default. ______________________________________________________________________ | Property Name | Data Type | Fast | Decription | |_________________|___________|_Access_|______________________________| | idle-state | int | Yes | CPU Idle state to enter | | idle-enter-ts | hrtime_t | Yes | Timestamp for entering idle | | idle-exit-ts | hrtime_t | Yes | Timestamp for exiting idle | | last-idle-time | hrtime_t | Yes | Last idle period | | last-busy-time | hrtime_t | Yes | Last busy period | | interrupt-count | uint64_t | Yes | Interrupt count in last busy | |_________________|___________|________| period_______________________| Other property providers may add new properties to framework in future. For example, CPU power management driver may support "idle-latency", "max-idle-time" etc. 6. Resources and Schedule: 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open --Boundary_(ID_16FJef+O3iIa56XuMfJjBA)-- From Artem.Kachitchkin@Sun.COM Fri Feb 27 10:21:40 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1RILdKm017961 for ; Fri, 27 Feb 2009 10:21:39 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1RILcjh001817; Fri, 27 Feb 2009 11:21:39 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFQ0080BLO2PR00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 27 Feb 2009 10:21:38 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFQ009WHLNM7IE0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 27 Feb 2009 10:21:38 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1RILMbp005529; Fri, 27 Feb 2009 10:21:22 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFQ00K00KRDLR00@fe-sfbay-09.sun.com>; Fri, 27 Feb 2009 10:21:22 -0800 (PST) Received: from [192.168.1.100] ([unknown] [75.6.230.171]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFQ00LVELNKOX30@fe-sfbay-09.sun.com>; Fri, 27 Feb 2009 10:21:20 -0800 (PST) Date: Fri, 27 Feb 2009 10:21:14 -0800 From: Artem Kachitchkine Subject: Re: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] In-reply-to: Sender: Artem.Kachitchkin@Sun.COM To: "Liu, Jiang" Cc: "Garrett D'Amore" , "Raj, Ashok" , Randy Fishel , "PSARC-ext@sun.com" , "tesla-dev@opensolaris.org" , "Wang, Frank" Message-id: <49A82F1A.9020107@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <499C6D90.6020603@sun.com> <499C7DD8.7000901@sun.com> <647EFE31A07A4A478691C20DABDFFCB12FF2FEE0@orsmsx501.amr.corp.intel.com> <499C890C.3050707@sun.com> <499E264E.5030206@sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 626 Liu, Jiang wrote: > Hi Randy, Garrent and Artem, > I have made some changes/enhancements to CPU idle notification PSARC > onepager according to kindly feedbacks from PSARC/Tesla review. Could you please > help to review it again? The attachments is the latest PSARC onepager and a diff file > with previous version. The main changes include: > 1) Add more comments to function parameters and return value. > 2) Provide a suite of interfaces to access CPU idle properties instead > of directly accessing data structure fields in previous version. > 3) Add constraints to call some interfaces. Looks good to me! -Artem From randy.fishel@SUN.COM Tue Mar 3 16:59:45 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n240xiC6027182 for ; Tue, 3 Mar 2009 16:59:45 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n240xdhY022952; Wed, 4 Mar 2009 08:59:42 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFY00G03IRG1E00@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Mar 2009 16:59:40 -0800 (PST) Received: from grimmy.sfbay.sun.com ([129.146.108.114]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFY00EULIRGPH20@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Mar 2009 16:59:40 -0800 (PST) Received: from grimmy.eng.sun.com (localhost [127.0.0.1]) by grimmy.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n240iYUG029442; Tue, 03 Mar 2009 16:44:34 -0800 (PST) Received: from localhost (randyf@localhost) by grimmy.eng.sun.com (8.13.8+Sun/8.13.8/Submit) with ESMTP id n240iYcs029438; Tue, 03 Mar 2009 16:44:34 -0800 (PST) Date: Tue, 03 Mar 2009 16:44:33 -0800 (PST) From: Randy Fishel Subject: Re: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] In-reply-to: <49A82F1A.9020107@sun.com> X-X-Sender: randyf@grimmy To: "PSARC-ext@sun.com" Cc: Artem Kachitchkine , "Liu, Jiang" , "Garrett D'Amore" , "Raj, Ashok" , "tesla-dev@opensolaris.org" , "Wang, Frank" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <499C6D90.6020603@sun.com> <499C7DD8.7000901@sun.com> <647EFE31A07A4A478691C20DABDFFCB12FF2FEE0@orsmsx501.amr.corp.intel.com> <499C890C.3050707@sun.com> <499E264E.5030206@sun.com> <49A82F1A.9020107@sun.com> X-Authentication-warning: grimmy.eng.sun.com: randyf owned process doing -bs User-Agent: Alpine 1.10 (GSO 962 2008-03-14) Status: RO Content-Length: 1014 On Fri, 27 Feb 2009, Artem Kachitchkine wrote: > Liu, Jiang wrote: > > Hi Randy, Garrent and Artem, > > I have made some changes/enhancements to CPU idle notification PSARC > > onepager according to kindly feedbacks from PSARC/Tesla review. Could you > > please > > help to review it again? The attachments is the latest PSARC onepager and a > > diff file with previous version. The main changes include: > > 1) Add more comments to function parameters and return value. > > 2) Provide a suite of interfaces to access CPU idle properties instead > > of directly accessing data structure fields in previous version. 3) Add > > constraints to call some interfaces. > > Looks good to me! > > -Artem > I forgot to mention that I put Gerry's spec update and diffs in the case directory, should someone want to re-review it (spec.txt, spec.diff). I have also reset the timer to 3/6. I hadn't seen any comments since Artem's, but want to give others further chance to make any comments. ---- Randy From gdamore@sun.com Tue Mar 3 20:19:22 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n244JLwX002257 for ; Tue, 3 Mar 2009 20:19:22 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n244JFNq021065; Wed, 4 Mar 2009 12:19:19 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFY00503S06HC00@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Mar 2009 20:19:18 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFY00NY2S055580@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Mar 2009 20:19:18 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n244JHeK004553; Tue, 03 Mar 2009 20:19:17 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFY00000RMP7L00@fe-sfbay-10.sun.com>; Tue, 03 Mar 2009 20:19:17 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFY00JRXS04NG80@fe-sfbay-10.sun.com>; Tue, 03 Mar 2009 20:19:17 -0800 (PST) Date: Tue, 03 Mar 2009 20:19:16 -0800 From: "Garrett D'Amore" Subject: Re: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] In-reply-to: Sender: Garrett.Damore@sun.com To: Randy Fishel Cc: "PSARC-ext@sun.com" , Artem Kachitchkine , "Liu, Jiang" , "Raj, Ashok" , "tesla-dev@opensolaris.org" , "Wang, Frank" Message-id: <49AE0144.90409@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <499C6D90.6020603@sun.com> <499C7DD8.7000901@sun.com> <647EFE31A07A4A478691C20DABDFFCB12FF2FEE0@orsmsx501.amr.corp.intel.com> <499C890C.3050707@sun.com> <499E264E.5030206@sun.com> <49A82F1A.9020107@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1352 I've not got time to spend on this right now... I'm very sorry. I'm leaving town for a week on Friday, and I am buried under my other work. If you can wait until after March 15 (I know, that's hard), you'll get a lot better response from me. -- Garrett Randy Fishel wrote: > On Fri, 27 Feb 2009, Artem Kachitchkine wrote: > > >> Liu, Jiang wrote: >> >>> Hi Randy, Garrent and Artem, >>> I have made some changes/enhancements to CPU idle notification PSARC >>> onepager according to kindly feedbacks from PSARC/Tesla review. Could you >>> please >>> help to review it again? The attachments is the latest PSARC onepager and a >>> diff file with previous version. The main changes include: >>> 1) Add more comments to function parameters and return value. >>> 2) Provide a suite of interfaces to access CPU idle properties instead >>> of directly accessing data structure fields in previous version. 3) Add >>> constraints to call some interfaces. >>> >> Looks good to me! >> >> -Artem >> >> > > > I forgot to mention that I put Gerry's spec update and diffs in the > case directory, should someone want to re-review it (spec.txt, > spec.diff). I have also reset the timer to 3/6. I hadn't seen any > comments since Artem's, but want to give others further chance to > make any comments. > > > ---- Randy > From gww@sac.sfbay.sun.com Wed Mar 4 10:12:17 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n24ICGlK029099 for ; Wed, 4 Mar 2009 10:12:17 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n24IC7nG024509; Thu, 5 Mar 2009 02:12:14 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFZ00E0HUKEDG00@brm-avmta-1.central.sun.com>; Wed, 04 Mar 2009 11:12:14 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFZ00IYFUKDY0E0@brm-avmta-1.central.sun.com>; Wed, 04 Mar 2009 11:12:13 -0700 (MST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n24ICCZm013984; Wed, 04 Mar 2009 10:12:12 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n24ICCBd029094; Wed, 04 Mar 2009 10:12:12 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n24ICCWw029093; Wed, 04 Mar 2009 10:12:12 -0800 (PST) Date: Wed, 04 Mar 2009 10:12:12 -0800 (PST) From: Gary Winiger Subject: Re: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] To: gdamore@sun.com, randy.fishel@sun.com Cc: Artem.Kachitchkin@sun.com, PSARC-ext@sun.com, ashok.raj@intel.com, frank.wang@intel.com, jiang.liu@intel.com, tesla-dev@opensolaris.org Message-id: <200903041812.n24ICCWw029093@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 407 > I've not got time to spend on this right now... I'm very sorry. I'm > leaving town for a week on Friday, and I am buried under my other work. > > If you can wait until after March 15 (I know, that's hard), you'll get a > lot better response from me. Randy asked me to represent him today. Garrett requested more time til 18 Mar. Garrett indicated that the project team was OK with this. Gary.. From gdamore@sun.com Fri Mar 6 00:02:09 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n268296m021404 for ; Fri, 6 Mar 2009 00:02:09 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n26828xf028157; Fri, 6 Mar 2009 00:02:09 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KG200G0DRNKDR00@brm-avmta-1.central.sun.com>; Fri, 06 Mar 2009 01:02:08 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KG200FM0RNJUB00@brm-avmta-1.central.sun.com>; Fri, 06 Mar 2009 01:02:07 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n26827Q2023896; Fri, 06 Mar 2009 00:02:07 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KG200K00RBNBW00@fe-sfbay-10.sun.com>; Fri, 06 Mar 2009 00:02:07 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KG200JOURNIH990@fe-sfbay-10.sun.com>; Fri, 06 Mar 2009 00:02:06 -0800 (PST) Date: Fri, 06 Mar 2009 00:02:06 -0800 From: "Garrett D'Amore" Subject: Re: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] In-reply-to: <200903041812.n24ICCWw029093@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Gary Winiger Cc: randy.fishel@sun.com, Artem.Kachitchkin@sun.com, PSARC-ext@sun.com, ashok.raj@intel.com, frank.wang@intel.com, jiang.liu@intel.com, tesla-dev@opensolaris.org Message-id: <49B0D87E.6040704@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903041812.n24ICCWw029093@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 539 Gary Winiger wrote: >> I've not got time to spend on this right now... I'm very sorry. I'm >> leaving town for a week on Friday, and I am buried under my other work. >> >> If you can wait until after March 15 (I know, that's hard), you'll get a >> lot better response from me. >> > > Randy asked me to represent him today. Garrett requested more > time til 18 Mar. Garrett indicated that the project team was > OK with this. > > Gary.. > I've looked at the revised case materials. Looks fine to me. +1. -- Garrett From gdamore@Sun.COM Wed Apr 1 10:09:32 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n31H9VTt019554 for ; Wed, 1 Apr 2009 10:09:32 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n31H9M3v016259; Thu, 2 Apr 2009 01:09:29 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHF00501MBR3200@brm-avmta-1.central.sun.com>; Wed, 01 Apr 2009 11:09:27 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHF00G99MBQZ5D0@brm-avmta-1.central.sun.com>; Wed, 01 Apr 2009 11:09:26 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n31H9QxR012902; Wed, 01 Apr 2009 10:09:26 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHF00900LZM7T00@fe-sfbay-10.sun.com>; Wed, 01 Apr 2009 10:09:26 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHF009L9MBP37A0@fe-sfbay-10.sun.com>; Wed, 01 Apr 2009 10:09:26 -0700 (PDT) Date: Wed, 01 Apr 2009 10:09:25 -0700 From: "Garrett D'Amore" Subject: Re: CPU Idle Notification [PSARC/2009/115 FastTrack timeout 02/25/2009] In-reply-to: <49B0D87E.6040704@sun.com> Sender: Garrett.Damore@Sun.COM To: Gary Winiger Cc: randy.fishel@Sun.COM, Artem.Kachitchkin@Sun.COM, psarc-ext@Sun.COM, ashok.raj@intel.com, frank.wang@intel.com, jiang.liu@intel.com, tesla-dev@opensolaris.org Message-id: <49D39FC5.9090104@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903041812.n24ICCWw029093@sac.sfbay.sun.com> <49B0D87E.6040704@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 702 Garrett D'Amore wrote: > Gary Winiger wrote: >>> I've not got time to spend on this right now... I'm very sorry. I'm >>> leaving town for a week on Friday, and I am buried under my other work. >>> >>> If you can wait until after March 15 (I know, that's hard), you'll >>> get a lot better response from me. >>> >> >> Randy asked me to represent him today. Garrett requested more >> time til 18 Mar. Garrett indicated that the project team was >> OK with this. >> >> Gary.. >> > > I've looked at the revised case materials. Looks fine to me. +1. > > -- Garrett > This case was approved at PSARC today. (It timed out anyway, so this is just a formality.) -- Garrett