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. I am all for making isolcpus changeable at run time. I just want to prevent it being changed accidentally at run time, by system tools that want to place their workloads in cpusets. -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
