Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752731Ab0FDHOj (ORCPT ); Fri, 4 Jun 2010 03:14:39 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:56032 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752636Ab0FDHOi (ORCPT ); Fri, 4 Jun 2010 03:14:38 -0400 Date: Fri, 4 Jun 2010 09:13:54 +0200 From: Ingo Molnar To: Arve Hj?nnev?g Cc: tytso@mit.edu, Brian Swetland , Neil Brown , Thomas Gleixner , "Rafael J. Wysocki" , Alan Stern , Felipe Balbi , Peter Zijlstra , LKML , Florian Mickler , Linux OMAP Mailing List , Linux PM , Alan Cox , James Bottomley , Linus Torvalds , Peter Zijlstra , Kevin Hilman , "H. Peter Anvin" , Arjan van de Ven Subject: Re: suspend blockers & Android integration Message-ID: <20100604071354.GA14451@elte.hu> References: <20100603193045.GA7188@elte.hu> <20100603231153.GA11302@elte.hu> <20100603232302.GA16184@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-08-17) X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.5 -2.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0001] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2040 Lines: 45 * Arve Hj?nnev?g wrote: > On Thu, Jun 3, 2010 at 4:23 PM, Ingo Molnar wrote: > ... > > ?- Controlled auto-suspend: drivers (such as input) could on wakeup > > ? automatically set the 'minimum wakeup latency' value of wakee tasks to a > > ? lower value. This automatically prevents another auto-suspend in the near > > ? future: up to the point the wakee task increases its latency (via the > > ? scheduler syscall) again and allows suspend again. > > > > How do you clear the latency value in a safe way? If another wakeup event > happens right after your wakee task is done processing the last event and > decides to increase its latency, auto suspend will be allowed even though > you have an unprocessed wakeup event. Also how do you know which task will > read the event if it is not already waiting for it? The easiest solution would be to not do any of that initially. (If it's ever a concern we could subtract/add without destroying the nesting property) Why do you need to track input wakeups? It's rather fragile and rather unnecessary - the idle drivers know it very well how to not go into the deepest idle mode already today. We wont hit C8 on laptops when you are using the desktop. > > ? This means there will be no surprise suspends for a task that may take a > > ? bit longer than usual to finish its work. [ Detail: this would only be done > > ? for tasks that have a non-default (non-infinity) task->latency value - to > > ? prevent the input driver from lowering latency values (and preventing > > ? future suspends) just because some unaware apps are running and using input > > ? drivers. ] > > Don't you need two inifinity values for this? Yes - any value above the max idle latency in the system will do. Thanks, Ingo -- 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/