From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752761AbbBXONN (ORCPT ); Tue, 24 Feb 2015 09:13:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45617 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752713AbbBXONM (ORCPT ); Tue, 24 Feb 2015 09:13:12 -0500 Message-ID: <54EC86F0.8080107@redhat.com> Date: Tue, 24 Feb 2015 09:13:04 -0500 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mike Galbraith CC: linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2] cpusets,isolcpus: resolve conflict between cpusets and isolcpus References: <1424727906-4460-1-git-send-email-riel@redhat.com> <1424744326.10678.4.camel@gmail.com> In-Reply-To: <1424744326.10678.4.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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/23/2015 09:18 PM, Mike Galbraith wrote: > 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? There may be use cases where users want nohz_full, but still want the scheduler to automatically load balance the CPU. I am not sure whether we want nohz_full and isolcpus to always overlap 100%. On the other hand, any CPU that is isolated with isolcpus= probably wants nohz_full... - -- All rights reversed -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU7IbwAAoJEM553pKExN6DxpAIAIt3Wp1fYhyTiceCZPZj/75y aNdpa1tsdyZmC3UoqHlWPajhU9kz3LV88gkDuRVLkBSIbAdc+Krpj0QwU80SBpn8 MIRkzlDE5pHwqgpNEmY0dTI8OP/BWH6SzgkbAqACTeffR8glz49ELFL2IK9hSl4P 2j5gOc1sgBD24cpqComw0qpIJwhRfDTr270zHPzEcqwESYLD57Z6AZxLuz8UjDnD vgvmz5+zCeVKfPWfFSCUHGDZ56PuQAvQk0olAVp5pd6wwGoPyAMNJm12RgE2ru0M 8y/xyHAhbtzdV7XsdfBWWe6F4jmodvjhKKtqRdwGzQSGkJzxGjdlFBeSkOkeBsk= =4dML -----END PGP SIGNATURE-----