Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752475AbbEROH2 (ORCPT ); Mon, 18 May 2015 10:07:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37987 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751947AbbEROH0 (ORCPT ); Mon, 18 May 2015 10:07:26 -0400 Message-ID: <5559F216.8050007@redhat.com> Date: Mon, 18 May 2015 10:07:18 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Mike Galbraith 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 Subject: Re: [PATCH 4/4] nohz: Set isolcpus when nohz_full is set 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> In-Reply-To: <1431919756.2518.51.camel@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1456 Lines: 32 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. I am all for making isolcpus changeable at run time. I just want to prevent it being changed accidentally at run time, by system tools that want to place their workloads in cpusets. -- All rights reversed -- 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/