Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933455Ab0FEWUx (ORCPT ); Sat, 5 Jun 2010 18:20:53 -0400 Received: from casper.infradead.org ([85.118.1.10]:42337 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933099Ab0FEWUv convert rfc822-to-8bit (ORCPT ); Sat, 5 Jun 2010 18:20:51 -0400 Date: Sat, 5 Jun 2010 15:23:26 -0700 From: Arjan van de Ven To: Arve =?UTF-8?B?SGrDuG5uZXbDpWc=?= Cc: Peter Zijlstra , Ingo Molnar , tytso@mit.edu, Brian Swetland , Neil Brown , Thomas Gleixner , "Rafael J. Wysocki" , Alan Stern , Felipe Balbi , LKML , Florian Mickler , Linux OMAP Mailing List , Linux PM , Alan Cox , James Bottomley , Linus Torvalds , Kevin Hilman , "H. Peter Anvin" Subject: Re: suspend blockers & Android integration Message-ID: <20100605152326.7ccd5160@infradead.org> In-Reply-To: References: <20100603193045.GA7188@elte.hu> <20100603231153.GA11302@elte.hu> <20100603232302.GA16184@elte.hu> <20100604071354.GA14451@elte.hu> <20100604083423.GD15181@elte.hu> <1275653210.27810.39762.camel@twins> <1275731653.27810.41078.camel@twins> <20100605092851.6ee15f13@infradead.org> Organization: Intel X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2261 Lines: 61 On Sat, 5 Jun 2010 14:26:14 -0700 Arve Hjønnevåg wrote: > On Sat, Jun 5, 2010 at 9:28 AM, Arjan van de Ven > wrote: > > On Sat, 05 Jun 2010 11:54:13 +0200 > > Peter Zijlstra wrote: > > > >> On Fri, 2010-06-04 at 17:10 -0700, Arve Hjønnevåg wrote: > >> > > Trusted processes are assumed to be sane and idle when there is > >> > > nothing for them to do, allowing the machine to go into deep > >> > > idle states. > >> > > > >> > > >> > Neither the kernel nor our trusted user-space code currently > >> > meets this criteria. > >> > >> Then both need fixing. Really, that's the only sane approach. > > > > fwiw... in MeeGo we're seeing quite good idle times (> 1 seconds) > > without really bad hacks. > > > > We clearly have different standards for what we consider good. We > measure time suspended in minutes or hours, not seconds, and waking up > every second or two causes a noticeable decrease in battery life on > the hardware we have today. I guess I'm spoiled working with (unreleased) hardware that knows how to power gate ;-) > > > the kernel has a set of infrastructure already to help here (range > > timers, with which you can wakeup-limit untrusted userspace crap), > > timer slack for legacy background timers, etc etc. > > Range timers allows the kernel to align different timers so they don't > each bring the cpu out of idle individually. They do not eliminate > timers or make individual timers fire less often. you're incorrect. With range timers you can control the rate at which timers fire just fine. For example if the Adobe Flash player puts a timer every 10 milliseconds (yes it does that), and you give it a 3.99 seconds range, it will fire its timers every 4 seconds.... unless other activity happens independently, at which point it'll align with that instead. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/