[libvirt] [PATCH 2/3] qemu_driver: clamp value for setting sched cpu_shares with --config.

[Dongsheng Yang]

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. :(