[CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.

[Andriy Gapon]

on 20/06/2012 00:42 Sean Bruno said the following:
> On Tue, 2012-06-19 at 14:07 -0700, Andriy Gapon wrote:
>> on 19/06/2012 19:02 Sean Bruno said the following:
>>> The first impact of this behavior is to list C3 as C2 in the list of
>>> Cstates when you retrieve the cx_supported sysctls for the cpus.
>>
>> I do not think that this is a real problem.  A cosmetic one - most likely.
>>
> Yes, most likely.  Except that the code seems to think that the index of
> the Cstates is good enough for a comparison to value.  More over, the
> sysctl's accept a value like "C3" and manipulate that into an index into
> the Cstate array without checking for the Cstate value.
> 
> The impact of this patch corrects this cosmetic display issue.  

If you accept that there are "FreeBSD C-states" and everything is done in terms
of them, then there is no problem.
I once wrote this trivial patch to see more information about FreeBSD-reported
C-states:
https://gitorious.org/~avg/freebsd/avgbsd/commit/043e9b0da5b46d389971e0166789fbee8a4e8622?format=patch

>>> The
>>> second impact is that the power_profile script never drops to a valid
>>> Cstate when you set the economy_lowest variable in rc.conf.
>>
>> Could you please explain if this somehow follows from your first observation and
>> how?
>> If not, could you please share your finding on what exactly causes this to happen?
>>
>> Also, are we talking about a laptop here?  Namely, judging from the reference to
>> 'economy_lowest', are AC state changes in play?
>>
> 
> No, what I was attempting to do was configure a server such that it
> would attempt to use the C3 state at idle.  Since the server gets
> configured by the power_state scripts via devd, the server is never
> configured with its global cx_lowest as anything other than C1.  e.g:
> 
> -bash-4.2$ sysctl -a|grep cx_lowest
> hw.acpi.cpu.cx_lowest: C1
> dev.cpu.0.cx_lowest: C1
> dev.cpu.1.cx_lowest: C1
> 
> -bash-4.2$ sysctl -a|grep cx_supported
> dev.cpu.0.cx_supported: C1/1 C2/96
> dev.cpu.1.cx_supported: C1/1 C2/96
> 
> 
> It seems that the rc.conf value of performance_cx_lowest="LOW" is what I
> really want, not economy_cx_lowest. 

Yes.  Could you please try this without using your patch?

I get an impression that its effect was to actually request C2 when cx_lowest is
set to C1.

-- 
Andriy Gapon