[libvirt] [PATCH v3] memtune: Let virsh know the unlimited value for memory tunables
Eric Blake
eblake at redhat.com
Wed Jan 12 17:21:04 UTC 2011
On 01/12/2011 12:56 AM, Nikunj A. Dadhania wrote:
> Here is the patch, now the set calls are also ull.
>
> Still virCgroupGetMemoryUsage is not changed, this will require changes
> in virDomainInfoPtr (info->memory). I am not sure if I should have them
> in this patch.
It can be a separate patch, if desired, but it is probably still needed.
virDomainGetInfo is inherently limited - we can't change that API due to
backwards compatibility issues, so if we ever encounter a system with
more than 4T memory (1k * 4G limit of unsigned long), then the maxMem
and memory fields of virDomainInfoPtr have to be clamped at 4G on any
system with 32-bit long, rather than wrapping around. We probably also
ought to document this limitation, and point to getMemoryParameter as
the way to find a more accurate memory limits if virDomainGetInfo
returned clamped values.
> From: Nikunj A. Dadhania <nikunj at linux.vnet.ibm.com>
>
> Display unlimited when the memory cgroup settings says so. Unlimited is
> represented by INT64_MAX in memory cgroup.
>
> v3: Make virCgroupSet memory call ull
> +++ b/src/util/cgroup.c
> @@ -858,8 +858,11 @@ int virCgroupForDomain(virCgroupPtr driver ATTRIBUTE_UNUSED,
> *
> * Returns: 0 on success
> */
> -int virCgroupSetMemory(virCgroupPtr group, unsigned long kb)
> +int virCgroupSetMemory(virCgroupPtr group, unsigned long long kb)
> {
> + if (kb > (VIR_DOMAIN_MEMORY_PARAM_UNLIMITED >> 10))
> + return -EINVAL;
> +
> return virCgroupSetValueU64(group,
> VIR_CGROUP_CONTROLLER_MEMORY,
> "memory.limit_in_bytes",
Not quite right. What if I want to change from a finite limit back to
unlimited? Then virCgroupSetMemory(group, UINT64_MAX) must recognize
that kb == VIR_DOMAIN_MEMORY_PARAM_UNLIMITED, and call
virCgroupSetValueU64(INT64_MAX) rathe than virCgroupSetValueU64(kb<<10).
> @@ -883,6 +886,7 @@ int virCgroupGetMemoryUsage(virCgroupPtr group, unsigned long *kb)
> "memory.usage_in_bytes", &usage_in_bytes);
> if (ret == 0)
> *kb = (unsigned long) usage_in_bytes >> 10;
> +
> return ret;
Why the whitespace change?
> @@ -927,8 +936,11 @@ int virCgroupGetMemoryHardLimit(virCgroupPtr group, unsigned long *kb)
> *
> * Returns: 0 on success
> */
> -int virCgroupSetMemorySoftLimit(virCgroupPtr group, unsigned long kb)
> +int virCgroupSetMemorySoftLimit(virCgroupPtr group, unsigned long long kb)
> {
> + if (kb > (VIR_DOMAIN_MEMORY_PARAM_UNLIMITED >> 10))
> + return -EINVAL;
> +
Likewise on needing to allow the user to set the value back to unlimited.
> +++ 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"?
--
Eric Blake eblake at redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110112/5dae6a91/attachment-0001.sig>
More information about the libvir-list
mailing list