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

Matthias Bolte matthias.bolte at googlemail.com
Wed Jan 12 20:51:15 UTC 2011


2011/1/12 Eric Blake <eblake at 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"?
>

Why do we define VIR_DOMAIN_MEMORY_PARAM_UNLIMITED to UINT64_MAX
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?

Matthias




More information about the libvir-list mailing list