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