From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Gleixner Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) Date: Wed, 2 Jun 2010 11:07:07 +0200 (CEST) Message-ID: References: <201005302202.39511.rjw@sisk.pl> <201005312347.24251.rjw@sisk.pl> Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-305410675-1275469630=:2933" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: =?ISO-8859-15?Q?Arve_Hj=F8nnev=E5g?= Cc: "Rafael J. Wysocki" , Florian Mickler , Matthew Garrett , Alan Stern , Peter Zijlstra , Paul@smtp1.linux-foundation.org, LKML , felipe.balbi@nokia.com, Linux OMAP Mailing List , Linux PM , Alan Cox List-Id: linux-omap@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-305410675-1275469630=:2933 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 2 Jun 2010, Arve Hjønnevåg wrote: > 2010/6/2 Thomas Gleixner : > > 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 --8323328-305410675-1275469630=:2933--