Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753053AbbEROWV (ORCPT ); Mon, 18 May 2015 10:22:21 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:37336 "EHLO mail-wi0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752170AbbEROWR (ORCPT ); Mon, 18 May 2015 10:22:17 -0400 Message-ID: <1431958931.2496.189.camel@gmail.com> Subject: Re: [PATCH 4/4] nohz: Set isolcpus when nohz_full is set From: Mike Galbraith To: Rik van Riel Cc: Sasha Levin , Frederic Weisbecker , Ingo Molnar , LKML , Chris Metcalf , "Rafael J . Wysocki" , Peter Zijlstra , Dave Jones , Thomas Gleixner , Oleg Nesterov , "Paul E . McKenney" , Ingo Molnar , Martin Schwidefsky Date: Mon, 18 May 2015 16:22:11 +0200 In-Reply-To: <5559F216.8050007@redhat.com> 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> <55594BC0.9070005@redhat.com> <1431919756.2518.51.camel@gmail.com> <5559F216.8050007@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 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: 1493 Lines: 32 On Mon, 2015-05-18 at 10:07 -0400, Rik van Riel wrote: > On 05/17/2015 11:29 PM, Mike Galbraith wrote: > > On Sun, 2015-05-17 at 22:17 -0400, Rik van Riel wrote: > >> On 05/17/2015 01:30 AM, Mike Galbraith wrote: > >> > >>> Given that kernel initiated association to isolcpus, a user turning > >>> NO_HZ_FULL_ALL on had better not have much generic load to manage. If > >>> he/she does not have CPUSETS enabled, or should Rik's patch rendering > >>> isolcpus immutable be merged, > >> > >> My patch does not aim to make isolcpus immutable, it aims to make > >> isolcpus resistent to system management tools (like libvirt) > >> automatically undoing isolcpus the instant a cpuset with the default > >> cpus (inherited from the root group) is created. > > > > Aim or not, if cpusets is the sole modifier, it'll render isolcpus > > immutable, no? Cpusets could grow an override to the override I > > suppose, to regain control of the resource it thinks it manages. > > The other way would be to make /sys/devices/system/cpu/isolcpus > (which Greg KH promised he would queue up for 4.2) writable. Anything is better than override the override. That's easy, but the changelog would have to be farmed out to a talented used car salesman. -Mike -- 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/