[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH v3] memtune: Let virsh know the unlimited value for memory tunables

2011/1/12 Eric Blake <eblake redhat com>:
> On 01/12/2011 12:56 AM, Nikunj A. Dadhania wrote:
>> Here is the patch, now the set calls are also ull.

>> +++ b/tools/virsh.c
>> @@ -2987,9 +2987,14 @@ cmdMemtune(vshControl * ctl, const vshCmd * cmd)
>>                               params[i].value.l);
>>                      break;
>>                  case VIR_DOMAIN_MEMORY_PARAM_ULLONG:
>> -                    vshPrint(ctl, "%-15s: %llu\n", params[i].field,
>> -                             params[i].value.ul);
>> +                {
>> +                    if (params[i].value.ul == VIR_DOMAIN_MEMORY_PARAM_UNLIMITED)
>> +                        vshPrint(ctl, "%-15s: unlimited\n", params[i].field);
>> +                    else
>> +                        vshPrint(ctl, "%-15s: %llu\n", params[i].field,
>> +                                 params[i].value.ul);
> Do we want any back-compat considerations?  That is, if a newer virsh is
> talking to an older server, which still answered INT64_MAX>>10 instead
> of the new VIR_DOMAIN_MEMORY_PARAM_UNLIMITED, should we recognize that
> situation as another reason to print "unlimited"?

anyway when currently INT64_MAX >> 10 is supported to mean unlimited?
Why do we want to complicate all applications that use the memory
parameter API, because they effectively need to interpret two values
as unlimited? Are there any really compelling reasons to change the
value that means unlimited?

Another question: How do I set a memory parameter back to unlimited?
Do I need to specify INT64_MAX >> 10 as numeric value in virsh?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]