On 05/15/2014 09:20 PM, Eric Blake wrote:
On 05/15/2014 05:18 AM, Dongsheng Yang wrote:
Also, it can make the other "invalid" input, such as -1 and 262144+1,
Auto-wrapping -1 to maximum makes sense.
Actually, -1 is not the minmum-1, because the range is [2, 262144].
The reason -1 is converted to maxmum is that -1 is treated as unsigned
long of 2^64-1. Then clamp it to range is 262144.
But making other out-of-bounds
values, like 262144+1, be auto-clamped sounds risky, especially if the
kernel ever changes clamping boundaries.
There are two approaches for this issue I think.
(1), use SCHED_RANGE_CHECK() for cpu_shares, same with period and
quota, then
if the value is our of the range, raise an error.
(2), keep the behavior for out-of-bounds values in --config as what
it is in --live. --live
is depending on the conversion of cgroup, then we should follow the
style of cgroup in
--config too, right? It means 262144+1 should clamped to maxmum.
About the concern you mentioned that boundaries may be changed in
future, as I explained
in another mail in this thread, it is defined in private zone of
scheduler, I can not catch up
with a good idea to solve it. :(
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list