From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754137AbZBQOza (ORCPT ); Tue, 17 Feb 2009 09:55:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751802AbZBQOzV (ORCPT ); Tue, 17 Feb 2009 09:55:21 -0500 Received: from smtp-out003.kontent.com ([81.88.40.217]:34686 "EHLO smtp-out003.kontent.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751526AbZBQOzV (ORCPT ); Tue, 17 Feb 2009 09:55:21 -0500 From: Oliver Neukum Organization: Novell To: Matthew Garrett Subject: Re: [RFD] Automatic suspend Date: Tue, 17 Feb 2009 15:56:58 +0100 User-Agent: KMail/1.9.10 Cc: Brian Swetland , "Rafael J. Wysocki" , Arjan van de Ven , "Woodruff, Richard" , Alan Stern , Kyle Moffett , Benjamin Herrenschmidt , pm list , LKML , Arve =?iso-8859-1?q?Hj=F8nnev=E5g?= , Pavel Machek , Nigel Cunningham , mark gross , Uli Luckas , Igor Stoppa , Len Brown References: <20090217142001.GB12378@bulgaria.corp.google.com> <20090217142453.GA25530@srcf.ucam.org> In-Reply-To: <20090217142453.GA25530@srcf.ucam.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902171557.02149.oliver@neukum.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Tuesday 17 February 2009 15:24:53 schrieb Matthew Garrett: > On Tue, Feb 17, 2009 at 06:20:01AM -0800, Brian Swetland wrote: > > > Of course that still doesn't address userspace. Aggressively going to > > suspend lets us compensate for userspace programs that do somewhat silly > > things (I agree that it would be best if they didn't but they do and > > getting *everyone* to write their userspace code to avoid spinning or > > avoid waking up on short-duration timers to poll is a losing battle). > > Like Pavel pointed out, you could (in principle) handle this by sending > a SIGSTOP to everything. The obvious problem with doing so is that this > wouldn't result in the processes letting go of the devices, so you > wouldn't neccessarily actually get to enter the runtime idle state as a > result. Hmm. I'll think about this. They don't let go of the devices if you suspend either. If you want that you need active cooperation from user space. In fact if you suspend you give drivers the guarantee of not getting any output without prior notification, making their lives easier. Regards Oliver