From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932935Ab0EMUIq (ORCPT ); Thu, 13 May 2010 16:08:46 -0400 Received: from cavan.codon.org.uk ([93.93.128.6]:51190 "EHLO cavan.codon.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932141Ab0EMUIm (ORCPT ); Thu, 13 May 2010 16:08:42 -0400 Date: Thu, 13 May 2010 21:08:14 +0100 From: Matthew Garrett To: Tony Lindgren Cc: Alan Stern , Paul Walmsley , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Linux-pm mailing list , Kernel development list , Tejun Heo , Oleg Nesterov , Kevin Hilman , magnus.damm@gmail.com, "Theodore Ts'o" , mark gross , Arjan van de Ven , Geoff Smith , Brian Swetland , "Rafael J. Wysocki" , =?iso-8859-1?Q?Beno=EEt?= Cousson , linux-omap@vger.kernel.org, Vitaly Wool , Mark Brown , Liam Girdwood Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6) Message-ID: <20100513200814.GA20254@srcf.ucam.org> References: <20100513191717.GA3428@atomide.com> <20100513192522.GA19256@srcf.ucam.org> <20100513194205.GC3428@atomide.com> <20100513195349.GB19722@srcf.ucam.org> <20100513200003.GE3428@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100513200003.GE3428@atomide.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: mjg59@cavan.codon.org.uk X-SA-Exim-Scanned: No (on cavan.codon.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: > The system stays running because there's something to do. The system > won't suspend until all the processors hit the kernel idle loop and > the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. I think we could implement your suggestion more easily by just giving untrusted applications an effectively infinite amount of timer slack, but it still doesn't handle the case where an app behaves excrutiatingly badly. -- Matthew Garrett | mjg59@srcf.ucam.org