From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933904Ab0EZInn (ORCPT ); Wed, 26 May 2010 04:43:43 -0400 Received: from bombadil.infradead.org ([18.85.46.34]:41765 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932536Ab0EZInj convert rfc822-to-8bit (ORCPT ); Wed, 26 May 2010 04:43:39 -0400 Subject: Re: [PATCH 1/8] PM: Opportunistic suspend support. From: Peter Zijlstra To: Arve =?ISO-8859-1?Q?Hj=F8nnev=E5g?= Cc: "Rafael J. Wysocki" , Alan Stern , 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, Matthew Garrett , Greg KH , tytso@mit.edu, James Bottomley In-Reply-To: References: <201005252344.37639.rjw@sisk.pl> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Wed, 26 May 2010 10:42:22 +0200 Message-ID: <1274863342.5882.4850.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2010-05-25 at 15:33 -0700, Arve Hjønnevåg wrote: > The biggest problem here is not that it is hard to change our > user-space, but that the proposed change is inferior to what we have > now. It forces us to poll until all drivers stop aborting suspend. On > one hand we have people telling us that all code that polls is broken > and must be fixed (instead of suspending to limit the damage), and on > the other hand we have people suggesting we implement opportunistic > suspend by polling from user-space until suspend succeeds. No it does _not_. You're really not getting that Dmitry is proposing. So your proposal is that when we wake userspace, it opens /dev/suspend_blocker _before_ it consumes whatever event, consumes the event, deals with the event, then closes the suspend_blocker. Then the kernel, upon reaching a 0 suspend_blocker count, will try to suspend again. What Dmitry proposes is that, the app _before_ it consumes the event, pokes at this suspend manager, it increases a blocker count, then consumes the event (the kernel will _not_ auto-suspend), handles it and then again pokes the suspend manager, this time decreasing the blocker count. The suspend manager will, upon reaching a 0 block count, suspend the machine. If that fails, it means there's something to do, an app will inc, work, dec its count, and it will try again once it reaches 0 again. There is no polling what-so-ever in this model. The only thing is that the kernel will not try to auto-suspend and there is no user-space suspend blocker API.