On 05/15/2014 09:11 PM, Ján Tomko wrote:
On 05/15/2014 11:39 AM, Dongsheng Yang wrote:As shown in 'man virsh' about schedinfo: Note: The cpu_shares parameter has a valid value range of 0-262144; Negative values are wrapped to positive, and larger values are capped at the maximum. Therefore, -1 is a useful shorthand for 262144. On the Linux kernel, the values 0 and 1 are automatically converted to a minimal value of 2. it works well with --live, but not with --config. Example: # virsh schedinfo rhel7-ful --set cpu_shares=0 --config Scheduler : posix cpu_shares : 0 vcpu_period : 0 vcpu_quota : 0 emulator_period: 0 emulator_quota : 0 cpu_shares is 0 rather than expected 2. What's worse, when we start it again, it is the default value of cpu_shares 1024. Because when we set the value of cpu_shares, when flag is --live, write the value into cgroup/cpu.shares. Then it will convert the value into the range of [2, 262144]. When flag is --config, we set the value into vmdef immidiately and 0 means no settting for cpu_shares. When we start vm again, libvirt use default value(1024) for it.commit bdffab0d5c52d31bd71422b0b69665efb6650953 Author: Ján Tomko <jtomko@xxxxxxxxxx> CommitDate: 2014-03-26 10:10:02 +0100 Treat zero cpu shares as a valid value changed this behavior. After this commit, if you set cpu_shares to 0 via schedinfo --config, the 0 will be written in the XML and used on domain startup.
Indeed , it works.
To use the default value, the <shares> element needs to be removed from the XML before restarting the domain, this cannot be currently done via 'virsh schedinfo'.
And yes, my patch here is attempting to do the similar work in 'virsh schedinfo'.
Also, it can make the other "invalid" input, such as -1 and 262144+1, get the
expected output as manpage described.
Jan
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list