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

_______________________________________________
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Reply via email to