From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752716AbbBXCSu (ORCPT ); Mon, 23 Feb 2015 21:18:50 -0500 Received: from mail-wi0-f181.google.com ([209.85.212.181]:60777 "EHLO mail-wi0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751312AbbBXCSt (ORCPT ); Mon, 23 Feb 2015 21:18:49 -0500 Message-ID: <1424744326.10678.4.camel@gmail.com> Subject: Re: [PATCH 0/2] cpusets,isolcpus: resolve conflict between cpusets and isolcpus From: Mike Galbraith To: riel@redhat.com Cc: linux-kernel@vger.kernel.org Date: Tue, 24 Feb 2015 03:18:46 +0100 In-Reply-To: <1424727906-4460-1-git-send-email-riel@redhat.com> References: <1424727906-4460-1-git-send-email-riel@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9 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 On Mon, 2015-02-23 at 16:45 -0500, riel@redhat.com wrote: > Ensure that cpus specified with the isolcpus= boot commandline > option stay outside of the load balancing in the kernel scheduler. > > Operations like load balancing can introduce unwanted latencies, > which is exactly what the isolcpus= commandline is there to prevent. > > Previously, simply creating a new cpuset, without even touching the > cpuset.cpus field inside the new cpuset, would undo the effects of > isolcpus=, by creating a scheduler domain spanning the whole system, > and setting up load balancing inside that domain. The cpuset root > cpuset.cpus file is read-only, so there was not even a way to undo > that effect. > > This does not impact the majority of cpusets users, since isolcpus= > is a fairly specialized feature used for realtime purposes. 3/3: nohz_full cpus become part of that unified isolated map? -Mike