VIA EPIA 5000 and ACPI Cx levels
b. f.
bf1783 at googlemail.com
Thu Oct 14 19:43:38 UTC 2010
On 10/10/10, Bruce Cran <bruce at cran.org.uk> wrote:
> On Sunday 10 October 2010 21:49:30 b. f. wrote:
>
>> If it has an i8254, that can also be used in one-shot mode if
>> hint.attimer.0.timecounter=0 is used, since r212778.
>
> Thanks, I didn't know about that. After enabling it things are quite
> different: kern.eventtimer.periodic is now 1, and setting
> hw.acpi.cpu.cx_lowest=C2 results in 100% time being reported as being spent
> in
> C2 mode according to dev.cpu.0.cx_usage - using C3 causes the system to
> hang.
> Shouldn't a fully loaded CPU spent more time in C1 state though? When I run
> a
> program that results in 0% idle time cx_usage still reports that no time was
> spent in C1 state.
I'm not sure what is going on here: if you set
hint.attimer.0.timecounter="0" and kern.eventtimer.timer="i8254" in
/boot/loader.conf, then the system should try to use the i8254 in
one-shot mode, unless you've specifically set periodic mode. If
kern.eventtimer.periodic=1, then you are _not_ using one-shot mode.
If it was 0 before your latest changes, then you were previously using
one-shot mode. But, as I wrote earlier, for kern.hz<128 and
kern.eventtimer.singlemul=1, periodic mode may result in more sleeping
than one-shot mode, though at a price. This may be what you are
seeing.
The C-state used is determined in acpi_cpu_idle() in
src/sys/dev/acpica/acpi_cpu.c, if you are using ACPI. I think that if
the latency for the C2 state is low enough, the number of callouts and
interrupts sufficiently low, and the scheduler quanta large enough,
it's possible for your machine to mostly use C2 rather than C1. You
can take a look at the algorithm, and make some experiments. Note
that bus mastering activity, which can include routine USB polling,
may prevent the use of C3. This or the high latency of C3 may account
for your machine not using it. Also note that you shouldn't use a
LAPIC timer if you are using C3 or deeper sleep states.
b.
More information about the freebsd-questions
mailing list