Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752929AbbBYQiV (ORCPT ); Wed, 25 Feb 2015 11:38:21 -0500 Received: from shelob.surriel.com ([74.92.59.67]:34690 "EHLO shelob.surriel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752199AbbBYQiU (ORCPT ); Wed, 25 Feb 2015 11:38:20 -0500 From: riel@redhat.com To: linux-kernel@vger.kernel.org Subject: [PATCH -v2 0/2] cpusets,isolcpus: resolve conflict between cpusets and isolcpus Date: Wed, 25 Feb 2015 11:38:06 -0500 Message-Id: <1424882288-2910-1-git-send-email-riel@redhat.com> X-Mailer: git-send-email 2.1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1166 Lines: 25 -v2 addresses the conflict David Rientjes spotted between my previous patches and commit e8e6d97c9b ("cpuset: use %*pb[l] to print bitmaps including cpumasks and nodemasks") 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. -- 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/