Messages in this thread | | | Date | Wed, 2 Jun 2010 11:07:07 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) |
| |
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote: > 2010/6/2 Thomas Gleixner <tglx@linutronix.de>: > > On Tue, 1 Jun 2010, Arve Hjønnevåg wrote: > >> > >> Because suspend itself causes you to not be idle you cannot abort > >> suspend just because you are not idle anymore. > > > > You still are addicted to the current suspend mechanism. :) > > > > No I want you to stop confusing low power idle modes with suspend. I > know how to enter low power modes from idle if that low power mode is > not too disruptive.
What prevents us from going into a disruptive mode from idle ? I don't see a reason - except crappy ACPI stuff, which I'm happy to ignore.
> > If I understood you correctly then you can shutdown the CPU in idle > > completelty already, but that's not enough due to: > > > > 1) crappy applications keeping the cpu away from idle > > 2) timers firing > > > > Would solving those two issues be sufficient for you or am I missing > > something ? > > Solving those two is enough for current android phones, but it may not > be enough for other android devices.
In which way ? May not be enough is a pretty vague statement.
> 1 is not solvable (meaning we cannot fix all apps),
We can mitigate it with cgroups and confine crap there, i.e. force idle them.
> and 2 is difficult to fix since the periodic > work is useful while the device is actually in use. One possible way > to solve 2 is to allow timers on a not-idle clock.
That's what I had in mind.
> Unrelated to Android, I also want to use opportunistic suspend on my > desktop.
I expect that intel/amd fixing their stuff is going to happen way before we sprinkled suspend blockers over a full featured desktop distro.
Thanks,
tglx | |