From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757600Ab0E0JHZ (ORCPT ); Thu, 27 May 2010 05:07:25 -0400 Received: from mail-px0-f174.google.com ([209.85.212.174]:59739 "EHLO mail-px0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751946Ab0E0JHX convert rfc822-to-8bit (ORCPT ); Thu, 27 May 2010 05:07:23 -0400 MIME-Version: 1.0 In-Reply-To: <1274948234.14002.27.camel@thorin> References: <1274863342.5882.4850.camel@twins> <20100526112303.3fef15a4@schatten.dmk.lab> <1274866402.5882.5051.camel@twins> <1274868384.5882.5169.camel@twins> <1274869262.5882.5222.camel@twins> <1274890736.4467.574.camel@mulgrave.site> <1274891308.1674.1766.camel@laptop> <20100526165919.GB2089@elf.ucw.cz> <1274893309.1674.1773.camel@laptop> <1274894685.4467.758.camel@mulgrave.site> <1274898180.4467.925.camel@mulgrave.site> <1274948234.14002.27.camel@thorin> Date: Thu, 27 May 2010 02:07:21 -0700 Message-ID: Subject: Re: [PATCH 1/8] PM: Opportunistic suspend support. From: =?ISO-8859-1?Q?Arve_Hj=F8nnev=E5g?= To: Bernd Petrovitsch Cc: James Bottomley , Thomas Gleixner , Peter Zijlstra , Pavel Machek , Pekka Enberg , Florian Mickler , "Rafael J. Wysocki" , Alan Stern , Dmitry Torokhov , Linux-pm mailing list , Kernel development list , Len Brown , Randy Dunlap , Andrew Morton , Andi Kleen , Cornelia Huck , Tejun Heo , Jesse Barnes , Nigel Cunningham , Ming Lei , Wu Fengguang , Maxim Levitsky , linux-doc@vger.kernel.org, Matthew Garrett , Greg KH , tytso@mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 27, 2010 at 1:17 AM, Bernd Petrovitsch wrote: > On Mit, 2010-05-26 at 13:23 -0500, James Bottomley wrote: >> On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote: > [...] >> > Darn, _we_ have to deal with that forever as it sets a crappy user >> > space ABI in stone. >> >> I really don't see how it is ... the ABI comes with a switch that allows >> it to be disabled, so only platforms wishing to use it have to support >> it.  Even on those platforms that do support it, we can translate most > > You completely missed the point: The crappy user interface - and > interferences with pother subsystems - must be maintained for ages - and > that is independent if one uses it or not. Even worse if it's not widely > used. When (or if) the time comes that suspend is no longer useful, this api becomes a NOP. > >> of it into pm QoS stuff and if one day someone solves the rogue app >> problem, we can migrate over. > > If it's so important for Android and no one else, Android can carry it > out of tree. > This is not only important for Android. If you use suspend on a current Linux system you run the risk of loosing wakeup events. If you have wakeup events that you cannot afford to lose your only option is to never suspend. On some hardware (e.g. x86) the cost of not suspending is always huge, on other hardware (many ARM SOCs) the cost is only huge if your apps behave poorly. -- Arve Hjønnevåg