* Thomas Renninger <trenn@xxxxxxx> 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.
Which is is the 'saner' model?
> 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.
But the actual code does not actually deal with any 'state 0', does it? It enters an
idle function and then exits it, right?
'power state' might be what is used for devices - but even there, we have:
- enter power state X
- exit power state
right?
> Same as done here with machine suspend state (S0 is back from suspend) and
> this model should get picked up when device sleep states get tracked at
> some time.
>
> It's consistent and applies to some well known specifications.
What we want it to be is for it to be the nicest, most understandable, most logical
model - not one matching random hardware specifications.
( Hardware specifications only matter in so far that it should be possible to
express all the known hardware state transitions via these events efficiently. )
> Also tracking processor_idle_{start,end} as a separate event 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.
What do you mean by "makes no sense"?
Are they superfluous? Inefficient? Illogical?
> Using state 0 as "exit/end", is much nicer for kernel/ userspace
> implementations/code and the user.
By that argument we should not have separate fork() and exit() syscalls either, but
a set_process_state(1) and set_process_state(0) interface?
Thanks,
Ingo
--
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
