Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)

[David Brownell]

> > during development on MeeGo devices we try to tackle
> down as much as
> > possible the use_time offenders and start by filing
> bugs to those apps,
> > instead of fixing their issues in kernel space.

Some apps do abuse kernel mechanisms, and whether the bug is in the
app or that kernel mechanism can be a judgement call.  I'd expect to
see some fixes be appropriately in-kernel; maybe not many though.

When reading about this suspend block stuff, does anyone else hear
eachoes of APM?  It's been ages since that was used, but ISTR it also
leveraged handshaking between kernel and userspace.  Are there lessons
to be applied from there to this discussion?

On first principles, I don't see anything wrong with acknowledging that
the kernel doesn't have a "whole system PM view" and thus its PM knowledge could usefully be augmented by information from userspace (applications), possibly on request.

Just what that broad PM view consists of gets kind of system-specific.  For OMAP hardware, with smart device-level power reduction active almost
all the time, it may look different from an ACPI laptop where the BIOS
is biased towards saving device power primarily in some suspend state(s) ... or some other hardware platform without much hardware or BIOS assist, where the main PM mechanisms involve software detection/instigation of hardware idleness (and potentially "off-ness").




> And you will continue doing that once the Meego app store
> has 100k apps?

I may have overlooked it, in one of the 100K messsages in my
mailbox about versions of suspend block/etc patches ...

But surely NOBODY is actually contending that broken aps NOT get fixed??

It's clear to me that tools are needed to identify power hogs; powertop can't be the extent of such tools.  (ISTR it doesn't monitor display power usage, for one thing; maybe newer versions do so.)  Once such hogs get identified they will need to get fixed.  Any other proposal seems broken to me...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/