Re: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.
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. 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? -- 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
Re: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.
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. 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. Sean ___ 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
Re: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.
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 ___ 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
