Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757185AbbEVOkH (ORCPT ); Fri, 22 May 2015 10:40:07 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:34157 "EHLO mail-wi0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756620AbbEVOkD (ORCPT ); Fri, 22 May 2015 10:40:03 -0400 Date: Fri, 22 May 2015 16:39:55 +0200 From: Frederic Weisbecker To: Mike Galbraith Cc: "Paul E. McKenney" , Afzal Mohammed , Sasha Levin , Ingo Molnar , LKML , Chris Metcalf , "Rafael J . Wysocki" , Peter Zijlstra , Dave Jones , Thomas Gleixner , Oleg Nesterov , Ingo Molnar , Rik van Riel , Martin Schwidefsky Subject: Re: [PATCH 4/4] nohz: Set isolcpus when nohz_full is set Message-ID: <20150522143952.GA24610@lerouge> References: <1430928266-24888-1-git-send-email-fweisbec@gmail.com> <1430928266-24888-5-git-send-email-fweisbec@gmail.com> <55579CE0.5060801@gmail.com> <1431840650.3222.78.camel@gmail.com> <20150520203809.GA2940@afzalpc> <20150520210026.GC6776@linux.vnet.ibm.com> <20150521121246.GA4723@afzalpc> <20150521125759.GL6776@linux.vnet.ibm.com> <20150521130621.GA14324@lerouge> <1432234778.3254.59.camel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1432234778.3254.59.camel@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2037 Lines: 43 On Thu, May 21, 2015 at 08:59:38PM +0200, Mike Galbraith wrote: > I think it's a mistake to make any rash assumption and/or mandate that > the user WILL use nohz_full CPUs immediately, or even at all for that > matter. nohz_full currently is nothing but a CPU attribute, period, > nothing more, nothing less. That's what the nohz_full parameter is for. Now if you're referring to change the nohz_full toggle to a runtime interface such as sysfs or such, I don't see that's a pressing need, especially considering the added complexity. At least I haven't heard much requests for it. > The overhead that comes with the it is the > only thing that suggests that the set really really should be used > exclusively for isolated compute loads, and even then, they had better > be pure userspace due to the hefty border crossing overhead. Yep. > > Let that overhear be seriously reduced, as per the Ingo/Andy discussion, > and presto, the things become a very interesting to dynamic sets. You > can really really use them as you see fit, and on the fly, it doesn't > cost you an arm and a leg just to turn it on. The only restriction > being the static set declaration, that you have to manage until that too > goes away. > > I see no reason to turn nohz_full into a rigid construct. I'm all for making nohz_full just about the tick and drive the rest of the isolation features through other settings. Ideally the isolation should be tuned by userspace, we have all the interface available for that: process affinity, irq affinity, workqueue affinity (soon), watchdog, etc... Then we'll also add syscall or prctl to loop on hard isolation (dataplane). Unfortunately people seem to prefer adding that complexity to the kernel and let it assume bold and unflexible pre-setting on its own. -- 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/