Re: pmf(9) vs sysmon for power events (especially sleep when powerd(8) is not running)

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On Fri, 6 May 2011 08:57:04 +0300, Jukka Ruohonen wrote:
> On Thu, May 05, 2011 at 05:56:43PM +0100, Jean-Yves Migeon wrote:
> The duplicity is a known and unfortunate issue. Also many drivers 
> suffer
> from this. My personal opinion is that we should either rework and 
> cleanup
> sysmon's power-related KPI or slowly deprecate it. But, still, pmf(9) 
> can
> not do the job alone (at least currently).

ack.

> So you take the stance that there will never be "normal" 
> (APM/ACPI/XXX)
> suspend states in Xen? I think Linux supports this already. Thus, 
> generally,
> any KPI should handle multiple "backends" with maybe slightly 
> diverging
> conceptual definitions.

There will, but only for dom0 (or any driver domain). DomUs are 
expected to be machine-agnostic, they are not supposed to rely on 
functionalities offered by the host they are currently running on. As 
Xen adds another abstraction layer, it also implements its own 
"suspension" mechanism, which is close to suspend to disk, except that 
the serialization is performed by dom0 and not by domU.

Shortly, a domU turns off all its CPUs, suspend I/Os and frontend 
devices, plays a bit with memory mapping, then signal dom0 that it can 
now safely dump its memory.

> This is quite adequate description. Note that it is still desirable 
> to have
> some (but not necessarily all) events delivered to user space. This 
> is the
> main task that is currently handled by the sysmon-routines + 
> powerd(8).

Yes. However, in the Xen domU case, it is quite unacceptable. Anyone 
willing to suspend a domain would launch "xm save" from dom0. If 
powerd(8) is not running, the "xm save" will wait ~forever for the domU 
to signal it's ready for suspension. I'd like to have a shortcut that 
handles the "powerd id not running" step, even if that means that 
specific services have not been turned off cleanly via 
scripts/sleep_button.

This situation also applies to power button too, but this case is 
already handled [1]. Albeit, not sleep, hence the XXX I believe.

> > Except for specific situation, "high level events" (LID open/close, 
> > power
> > button press) are first handled via sysmon, then injected to drivers 
> > via
> > pmf.
>
> In most cases it is either, not both.

I respectfully disagree. The PSWITCH_TYPE_LID event is first handled by 
sysmon(9), then injected in pmf(9). See [2].

> As said, the first approach requires a major cleanup and 
> rationalization of
> the "sysmon_power" backend. The second approach may sound reasonable 
> as an
> intermediate or a temporary solution for the immediate requirements 
> of 6.0.
> That is, I think no one expects you to write a full-blown KPI for 
> this --
> a task that is quite non-trivial, as is manifested by the current 
> duplicity.

Indeed. But I'd like to avoid going in the wrong direction, it makes 
the migration harder when the new KPI is blessed. I am a bit concerned 
because it's likely to be me that will do this migration work for Xen :)

> The sysmon_pswitch_register(9) is indeed a NOP (it is supposedly 
> there to
> account some possible future use). But sysmon_pswitch_event() is not 
> a NOP.
> It does not inject anything to pmf(9).

It does. See [2].

> > BTW, would the handler be supposed to be called only when powerd(8) 
> > is
> > running (with the sleep_button script execing zzz(8)), or could it 
> > be used
> > when it is not, including situation where there's no real thread 
> > context
> > (on interrupts)?
>
> Do not confuse the "sleep_button" script with the issue at hand. As 
> the
> names indicates, it delivers events from buttons that are physically 
> present
> on a computer. I think there should be no requirements for this to 
> work on
> interrupt context (if there is, the drivers should do something about 
> it).

Alright, this simplifies my design, thanks.

[1] 
http://nxr.netbsd.org/source/xref/src/sys/dev/sysmon/sysmon_power.c#949

[2] 
http://nxr.netbsd.org/source/xref/src/sys/dev/sysmon/sysmon_power.c#913

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost