[libvirt] [PATCH v3] cgroup: Use system reported "unlimited" value for comparison
mkletzan at redhat.com
Wed Dec 7 06:51:43 UTC 2016
On Tue, Dec 06, 2016 at 01:03:29PM +0100, Viktor Mihajlovski wrote:
>With kernel 3.18 (since commit 3e32cb2e0a12b6915056ff04601cf1bb9b44f967)
>the "unlimited" value for cgroup memory limits has changed once again as
>its byte value is now computed from a page counter.
>The new "unlimited" value reported by the cgroup fs is therefore 2**51-1
>pages which is (VIR_DOMAIN_MEMORY_PARAM_UNLIMITED - 3072). This results
>e.g. in virsh memtune displaying 9007199254740988 instead of unlimited
>for the limits.
>This patch uses the value of memory.limit_in_bytes from the cgroup
>memory root which is the system's "real" unlimited value for comparison.
>See also libvirt commit 231656bbeb9e4d3bedc44362784c35eee21cf0f4 for the
>history for kernel 3.12 and before.
>Signed-off-by: Viktor Mihajlovski <mihajlov at linux.vnet.ibm.com>
>- removed RFC verbiage from commit message
>- per Martin's review comment, cache the cgroup memory.limit_in_bytes
>- used the cgroup detection logic proposed by Martin, much nicer now indeed
>- other than initially planned, fall back to VIR_DOMAIN_MEMORY_PARAM_UNLIMITED
> in case of cgroup read failure, since the usual paranoia fits in nicely with
> the "already initialized" check. With the current code structure this will
> never be called when the memory controller is not configured or mounted
>- while at it, replaced the goto cleanups with direct returns as there's
> really no cleanup to be done in the GetMemoryxxxLimit functions
>- use thread safe one time initialization for the "unlimited" value, to
> account for 64-bit architectures which do not guarantee atomic memory
> updates of long long values (which reportedly is the case for ARM).
Perfect, ACK, pushed, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Digital signature
More information about the libvir-list