Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753109AbbEROwS (ORCPT ); Mon, 18 May 2015 10:52:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33067 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751231AbbEROwJ (ORCPT ); Mon, 18 May 2015 10:52:09 -0400 Message-ID: <5559FC90.1000603@redhat.com> Date: Mon, 18 May 2015 10:52:00 -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> <5559F216.8050007@redhat.com> <1431958931.2496.189.camel@gmail.com> In-Reply-To: <1431958931.2496.189.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: 1987 Lines: 45 On 05/18/2015 10:22 AM, Mike Galbraith wrote: > 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. For real time KVM, it is desirable to run the VCPU threads on isolated CPUs as real time tasks. Meanwhile, the emulator threads can run as normal tasks anywhere on the system. This means the /machine cpuset, which all guests live under, needs to contain all the system's CPUs, both isolated and non-isolated, otherwise it will be unable to have the VCPU threads on isolated CPUs and the emulator threads on other CPUs. -- 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/