Re: [libvirt] [PATCH v3] cgroup: Use system reported "unlimited" value for comparison

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(a)linux.vnet.ibm.com&gt; > --- > > v2: - 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 anyway... - while at it, replaced the goto cleanups with > direct returns as there's really no cleanup to be done in the > GetMemoryxxxLimit functions > > v3: - 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.