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

[Brian Swetland]

On Mon, May 17, 2010 at 3:55 PM, Kevin Hilman
<khilman@xxxxxxxxxxxxxxxxxxx> wrote:
>
> The fundamental problem is one of idleness. ÂWhat we want is the
> system to be idle in order to hit the lowest power states. ÂWe can't
> get there because the system is not truly idle.
>
> So, there are basically two solutions:
>
> 1) find and fix the problem spots so we can be idle more often
> 2) add a new definition of idle so we can be idle more often
>
> Opporuntistic suspend takes the second approach where the new
> definition of idle is "no suspend blockers held."
>
> Of course, I clearly prefer the former, but it's also becoming clear
> that since I'm the only one still whining about it, I must be too much
> of an idealist to keep hoping for it.

I'd love to see the former work, but it is not something that I think
is going to be fixed rapidly.  It potentially involves many different
subsystems, and still requires some need for managing arbitrary
userspace agents which may have non-ideal behaviors (if we're going to
solve the problem for general purpose devices that can run arbitrary
user-installed software).  Incremental improvements are great though
(for example, that we can now be in lowest power idle for periods
greater than 2 seconds due to the change in .32).

Even when operating in opportunistic suspend, it is still advantageous
for idle to be as idle as possible and we should keep working toward
that goal.  If we get to the point where the power difference between
suspend-in-idle and opportunistic suspend is zero, then we no longer
need the latter.

I don't think anybody on the Google/Android side is arguing that we
*shouldn't* pursue dynamic pm and overall making idle more idle more
of the time.  We're just saying that here and now we are not at the
ideal and opportunistic suspend gains us real power savings and is
useful.

Brian
--
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/