From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758179Ab0EZXJP (ORCPT ); Wed, 26 May 2010 19:09:15 -0400 Received: from mail-pz0-f176.google.com ([209.85.222.176]:59633 "EHLO mail-pz0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755110Ab0EZXJN convert rfc822-to-8bit (ORCPT ); Wed, 26 May 2010 19:09:13 -0400 MIME-Version: 1.0 In-Reply-To: References: <201005262351.59626.rjw@sisk.pl> Date: Wed, 26 May 2010 16:09:12 -0700 Message-ID: Subject: Re: [PATCH 1/8] PM: Opportunistic suspend support. From: =?ISO-8859-1?Q?Arve_Hj=F8nnev=E5g?= To: Alan Stern Cc: "Rafael J. Wysocki" , Dmitry Torokhov , Linux-pm mailing list , Kernel development list , Len Brown , Pavel Machek , 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 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 Wed, May 26, 2010 at 3:12 PM, Alan Stern wrote: > On Wed, 26 May 2010, Rafael J. Wysocki wrote: > >> > The reason is simple: When a user process initiates an opportunistic >> > suspend, you make it wait in an interruptible sleep until all the >> > kernel suspend blockers are released.  No polling.  If another user >> > thread decides in the meantime that it needs to block the suspend, it >> > sends a signal to the power manager process. >> > >> > In fact, other threads should signal the power manager process whenever >> > they want to block or unblock suspends.  That way the power manager >> > process can spend all its time sleeping, without doing any polling. >> >> I still see an issue here.  Namely, if the power manager is in user space and >> it's signaled to suspend, it has to ask the kernel to do that, presumably by >> writing something to a sysfs file.  Then, if the kernel blocks the suspend, the >> power manager waits until the block is released.  Now, it should go back and >> check if user space still doesn't block suspend and if so, wait until the block >> is released and start over.  With all suspend blockers in the kernel this >> looping behavior is avoidable. > > I must be missing something.  In Arve's patch 1/8, if the system is in > opportunistic suspend, and a wakeup event occurs but no suspend > blockers get enabled by the handler, what causes the system to go back > into suspend after the event is handled?  Isn't that a loop of some > sort? > Yes it is a loop. I think what you are missing is that it only loops repeatedly if the driver that aborts suspend does not use a suspend blocker. > And even if it isn't, so what?  What's wrong with looping behavior? It is a significant power drain. > Especially a loop that's as short as this one and spends almost all of > its time sleeping.  Think how much harder it would be to write programs > if you weren't allowed to use any loops.  :-) > > Alan Stern > > -- Arve Hjønnevåg