Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755186Ab2JaAH6 (ORCPT ); Tue, 30 Oct 2012 20:07:58 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]:16352 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750916Ab2JaAH5 (ORCPT ); Tue, 30 Oct 2012 20:07:57 -0400 X-Authority-Analysis: v=2.0 cv=YP4dOG6x c=1 sm=0 a=rXTBtCOcEpjy1lPqhTCpEQ==:17 a=mNMOxpOpBa8A:10 a=bYqEZP2IH2oA:10 a=5SG0PmZfjMsA:10 a=Q9fys5e9bTEA:10 a=meVymXHHAAAA:8 a=ED5KP61D5LcA:10 a=WEIArCIlw_fgFkZjPx4A:9 a=PUjeQqilurYA:10 a=rXTBtCOcEpjy1lPqhTCpEQ==:117 X-Cloudmark-Score: 0 X-Originating-IP: 74.67.115.198 Message-ID: <1351642073.4004.38.camel@gandalf.local.home> Subject: Re: [PATCH 04/32] x86: New cpuset nohz irq vector From: Steven Rostedt To: Frederic Weisbecker Cc: linux-kernel@vger.kernel.org, Andrew Morton , Thomas Gleixner , Peter Zijlstra , Clark Williams , Ingo Molnar , "Paul E. McKenney" , Mike Galbraith , Alessio Igor Bogani , Avi Kivity , Chris Metcalf , Christoph Lameter , Daniel Lezcano , Geoff Levand , Gilad Ben Yossef , Hakan Akkan , Kevin Hilman , Stephen Hemminger , Sven-Thorsten Dietrich Date: Tue, 30 Oct 2012 20:07:53 -0400 In-Reply-To: References: <20121029202711.062749374@goodmis.org> <20121029203847.242305452@goodmis.org> <1351618787.8467.136.camel@gandalf.local.home> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1458 Lines: 45 On Wed, 2012-10-31 at 00:51 +0100, Frederic Weisbecker wrote: > > Probably just use irq_work for self ipis, and normal ipis for other > > CPUs. > > Right. And that's one more reason why we want to know if the arch > implements irq work with self ipis or not. If the arch can't, then we > just don't stop the tick. We can just allow certain archs to have cpuset/nohz. Make it depend on features that you want (or makes nohz easier to implement). > > > Also, what reason do we have to force a task out of nohz? IOW, do we > > really need this? > > When a posix CPU timer is enqueued, when a new task is enqueued, etc... I was thinking about something other than itself. That is, who would enqueue a posix cpu timer on the cpu other than the task running with nohz on that cpu? A new task would send the schedule ipi too. Which would enqueue the task and take the cpu out of nohz, no? > > > > > Also, perhaps we could just tag onto the schedule_ipi() function instead > > of having to create a new IPI for all archs? > > irq work should be just fine. No need to add more overhead on the > schedule ipi I think. irq_work can send the work to another CPU right? This part I wasn't sure about. -- Steve -- 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/