On Thu, 6 May 2004, Len Brown wrote:
> On Thu, 2004-05-06 at 12:37, Mike Silbersack wrote:
> > On Thu, 6 May 2004, Nate Lawson wrote:
> > > hw.acpi.cpu.cx_supported: C1/0 C2/84 C3/120
> > > hw.acpi.cpu.cx_lowest: 1
> > > hw.acpi.cpu.cx_history: 9175/0 173443/9175 0/0
> > >
> > > This means I am requesting a lowest sleep of C2 (idx 1 of the options
> > > supported). The history values show that I haven't used C3 at all and am
> > > using C2 at a rate of about 95%.
> > Something else must be happening, because:
> > hw.acpi.cpu.cx_supported: C1/1 C2/99 C3/288
> > hw.acpi.cpu.cx_lowest: 0
> > hw.acpi.cpu.cx_history: 5558639/0 0/0 0/0
> > But, since I went and killed the scheduling overrun interrupts at the
> > source, we don't need to worry anymore. :)
> I expect that C2/99 means the FADT lists C2 latency as 99usec.
> Similarly for 288 usec C3 latency.
> This compares to the ACPI spec limits of 100 and 1000, respectively.
> This is relativly high latency, and the OS may decided that it isn't
> worth paying it.
We don't attempt to make policy decisions here. By default, you get C1 on
AC power and the lowest available when offline. If the user decides this
hurts performance when offline, it's their job to override it.
BTW, I'm going to change cx_lowest to be a string like "C3" instead of an
index. For Cx values > C3, I'll just artificially generate C4, C5, C6,