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@xxxxxxxxxxxxxxxxxx> --- 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.
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
