-----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, r...@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----- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
