On Monday, October 25, 2010, Arjan van de Ven wrote:
> On 10/25/2010 4:03 AM, Thomas Renninger wrote:
> > On Monday 25 October 2010 12:04:28 Ingo Molnar wrote:
> >> * Thomas Renninger<trenn@xxxxxxx> wrote:
> >>
> >>> New power trace events:
> >>> power:processor_idle
> >>> power:processor_frequency
> >>> power:machine_suspend
> >>>
> >>>
> >>> C-state/idle accounting events:
> >>> power:power_start
> >>> power:power_end
> >>> are replaced with:
> >>> power:processor_idle
> >> Well, most power saving hw models (and the code implementing them) have this kind of
> >> model:
> >>
> >> enter power saving mode X
> >> exit power saving mode
> >>
> >> Where X is some sort of 'power saving deepness' attribute, right?
> > Sure.
> > But ACPI and afaik this model got picked up for PCI and other (sub-)archs
> > as well, defines state 0 as the non-power saving mode.
>
> correct ,... "C0" is not power efficient... but it's still a valid OS
> idle state!
> Also tracking processor_idle_{start,end} as a separate event!
>
> same for "S0"... S0 as standby state is still valid... sure it doesn't
> save you much power... but that does not mean it's not valid.
If you mean ACPI S0, it is not a standby state. It actually is the full-power
state.
> (as indication, the Intel Moorestown platform, which is currently in
> production and available to OEMs, has such a S0 standby state)
Another naming confusion. How smart.
> > makes no sense and there is no need to introduce:
> > processor_idle_start/processor_idle_end
> > machine_suspend_start/machine_suspend_end
> > device_power_mode_start/device_power_mode_end
> > events.
> > Using state 0 as "exit/end", is much nicer for kernel/
> > userspace implementations/code and the user.
> actually no; having written a few of these in userspace so far, having a
> separate end event is easier to deal with;
> the actions you take on entry and exit are complete separate code paths.
That's correct, unless you go directly from one low-power state to another
(which is possible for example for PCI). We don't do that at the moment,
but it's possible in principle and we may want to start doing that at one
point.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
