Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755942Ab0FCOzL (ORCPT ); Thu, 3 Jun 2010 10:55:11 -0400 Received: from cantor.suse.de ([195.135.220.2]:46785 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755627Ab0FCOzJ (ORCPT ); Thu, 3 Jun 2010 10:55:09 -0400 Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) From: James Bottomley To: Thomas Gleixner Cc: Peter Zijlstra , "Gross, Mark" , Neil Brown , LKML , Florian Mickler , "tytso@mit.edu" , Linux PM , Linux OMAP Mailing List , "felipe.balbi@nokia.com" , Alan Cox In-Reply-To: References: <20100527232357.6d14fdb2@lxorguk.ukuu.org.uk> <20100601135102.GA8098@srcf.ucam.org> <1275426085.21962.967.camel@mulgrave.site> <201006020024.14220.rjw@sisk.pl> <1275431816.21962.1108.camel@mulgrave.site> <1275451342.21962.1777.camel@mulgrave.site> <1275491111.2799.110.camel@mulgrave.site> <20100602214748.7742e3ae@schatten.dmk.lab> <1275511271.2799.516.camel@mulgrave.site> <20100603010607.5baf82a6@schatten.dmk.lab> <20100603110312.48a508dc@lxorguk.ukuu.org.uk> <1275571471.5914.2.camel@mulgrave.site> Content-Type: text/plain; charset="UTF-8" Date: Thu, 03 Jun 2010 09:55:00 -0500 Message-ID: <1275576900.5914.107.camel@mulgrave.site> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2075 Lines: 44 On Thu, 2010-06-03 at 16:35 +0200, Thomas Gleixner wrote: > On Thu, 3 Jun 2010, James Bottomley wrote: > > > On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote: > > > > [mtg: ] This has been a pain point for the PM_QOS implementation. They change the constrain back and forth at the transaction level of the i2c driver. The pm_qos code really wasn't made to deal with such hot path use, as each such change triggers a re-computation of what the aggregate qos request is. > > > > > > That should be trivial in the usual case because 99% of the time you can > > > hot path > > > > > > the QoS entry changing is the latest one > > > there have been no other changes > > > If it is valid I can use the cached previous aggregate I cunningly > > > saved in the top QoS entry when I computed the new one > > > > > > (ie most of the time from the kernel side you have a QoS stack) > > > > It's not just the list based computation: that's trivial to fix, as you > > say ... the other problem is the notifier chain, because that's blocking > > and could be long. Could we invoke the notifier through a workqueue? > > It doesn't seem to have veto power, so it's pure notification, does it > > matter if the notice is delayed (as long as it's in order)? > > It depends on the information type and for a lot of things we might > get away without notifiers. > > The only real issue is when you need to get other cores out of their > deep idle state to make a new constraint work. That's what we do with > the DMA latency notifier right now. But the only DMA latency notifier is cpuidle_latency_notifier. That looks callable from atomic context, so we could have two chains: one atomic and one not. The only other notifier in use is the ieee80211_max_network_latency, which uses mutexes, so does require user context. James -- 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/