Date: Fri, 06 Jul 2012 16:32:52 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Sean Bruno <seanbru@yahoo-inc.com> Cc: freebsd-acpi@FreeBSD.org, John Baldwin <jhb@FreeBSD.org> Subject: Re: [rethinking] Re: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing. Message-ID: <4FF6E904.9000900@FreeBSD.org> In-Reply-To: <4FF45B71.7050208@FreeBSD.org> References: <1340756603.2898.12.camel@powernoodle.corp.yahoo.com> <4FF1D7A7.6000906@FreeBSD.org> <1341263872.3342.39.camel@powernoodle.corp.yahoo.com> <4FF45B71.7050208@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 04/07/2012 18:04 Andriy Gapon said the following: > Our current approach of using C-state indexes as C-state identifiers/names may be > not so bad after all if we remove confusion by properly documenting the meaning > (index vs "type"). > Here is a link to a past discussion on this topic: > http://thread.gmane.org/gmane.os.freebsd.current/127860/focus=6373 > I think that messages in a sub-thread starting at the highlighted message may > provide some useful information. > Here are couple of links to the code in Linux and OpenSolaris: > http://lxr.linux.no/#linux+v3.4.4/drivers/acpi/processor_idle.c#L354 > http://lxr.linux.no/#linux+v3.4.4/drivers/acpi/processor_idle.c#L1097 > http://fxr.watson.org/fxr/source/i86pc/os/cpupm/cpu_acpi.c?v=OPENSOLARIS#L683 > http://fxr.watson.org/fxr/source/i86pc/os/cpupm/cpu_idle.c?v=OPENSOLARIS;im=bigexcerpts#L678 > > So, now as then I still don't have any preference for either of methods. But the > decision is not straightforward as you might see now, thus we need some convincing > that any change is needed actually :-) > > For more information about each C-state I would go a way of creating a sysctl > forest with a tree at each C-state under each CPU (for potential asymmetric > C-state support), which would describe all available parameters of each C-state > (power, latency, ACPI (or HW-specific[*]) type, I/O-vs-MWAIT-vs-etc type of > entrance, etc). > > [*] E.g. for intel_idle it could be C-state numbers from Intel specs. > Here is an example based on a real i7 system (enslaved by Linux) to make the situation more easy to comprehend. The system seems to provide 5 C-states including C0, but uninteresting C0 and C1 will be omitted in the further data. So: ACPI (_CST) index 2 3 4 ACPI (_CST) type 2 3 3 ACPI I/O register 0x414 0x415 0x416 Intel name (intel_idle) C3 C6 C7 MWAIT hint 0x10 0x20 0x30 [*] ACPI tables can advertise C-states either with I/O entry or with MWAIT entry based on declared OS capabilities (what FreeBSD defines as ACPI_CAP_SMP_C3_NATIVE, to be precise). MWAIT hints are the same both in ACPI tables and in intel_idle driver. I make the following observations and conclusions. All C-states are really different despite two of them having the same ACPI type. So collapsing C-states based on ACPI type like (Open)Solaris does (did) is clearly a wrong approach. Using ACPI type as a name (identity) of a C-state also seems to be unhelpful ("C3 - which C3, the first C3 or the second C3?"). Restoring the vendor designated names of the states (C3, C6, C7) is impossible from ACPI provided information alone. Where does this leave us? I think that it leaves us exactly where we are now (and Linux too). The only thing that I would perhaps change would be to drop 'C' from FreeBSD C-state names to minimize confusion with "real" C-state name/types/whatevers (whichever one prefers to consider to be the real ones) and to emphasize that they are just indexes/handles/FreeBSD IDs. But even such a change, being purely cosmetic, probably has too little benefit considering potential pain of POLA violation. So I urge you to give up your C-state renaming patch. At least for me the above example decides the choice. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FF6E904.9000900>