From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759892Ab2BJSdy (ORCPT ); Fri, 10 Feb 2012 13:33:54 -0500 Received: from merlin.infradead.org ([205.233.59.134]:38686 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759727Ab2BJSdv (ORCPT ); Fri, 10 Feb 2012 13:33:51 -0500 Subject: Re: [v7 0/8] Reduce cross CPU IPI interference From: Peter Zijlstra To: Chris Metcalf Cc: Frederic Weisbecker , Gilad Ben-Yossef , linux-kernel@vger.kernel.org, Christoph Lameter , linux-mm@kvack.org, Pekka Enberg , Matt Mackall , Sasha Levin , Rik van Riel , Andi Kleen , Mel Gorman , Andrew Morton , Alexander Viro , Avi Kivity , Michal Nazarewicz , Kosaki Motohiro , Milton Miller In-Reply-To: <4F2AAEB9.9070302@tilera.com> References: <1327572121-13673-1-git-send-email-gilad@benyossef.com> <1327591185.2446.102.camel@twins> <20120201170443.GE6731@somewhere.redhat.com> <4F2AAEB9.9070302@tilera.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 10 Feb 2012 19:33:36 +0100 Message-ID: <1328898816.25989.33.camel@laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2012-02-02 at 10:41 -0500, Chris Metcalf wrote: > At Tilera we have been supporting a "dataplane" mode (aka Zero Overhead > Linux - the marketing name). This is configured on a per-cpu basis, and in > addition to setting isolcpus for those nodes, also suppresses various > things that might otherwise run (soft lockup detection, vmstat work, > etc.). See that's wrong.. it starts being wrong by depending on cpuisol and goes from there. > The claim is that you need to specify these kinds of things > per-core since it's not always possible for the kernel to know that you > really don't want the scheduler or any other interrupt source to touch the > core, as opposed to the case where you just happen to have a single process > scheduled on the core and you don't mind occasional interrupts. Right, so that claim is proven false I think. > But > there's definitely appeal in having the kernel do it adaptively too, > particularly if it can be made to work just as well as configuring it > statically. I see no reason why it shouldn't work as well or even better.