[17.06.1] Make Linux memory allocations int64 not uint64

[tiborvass]

The kernel ABI to these values is a string, which accepts the value -1
to mean "unlimited" or an integer up to 2^63 for an amount of memory in
bytes.

While the internal representation in the kernel is unsigned, this is not
exposed in any ABI directly. Because of the user-kernel memory split, values
over 2^63 are not really useful; indeed that much memory is not supported,
as physical memory is limited to 52 bits in the forthcoming switch to five
level page tables. So it is much more natural to support the value -1 for
unlimited, especially as the actual number needed to represent the maximum
has varied in different kernel versions, and across 32 and 64 bit architectures,
so determining the value to use is not possible, so it is necessary to write
the string -1 to the cgroup files.

See also discussion in

• Fix unlimited memory issue on old kernel opencontainers/runc#1494
• Revert memory fields to signed integers opencontainers/runc#1492
• Use uint64 for resources to keep consistency with runtime-spec opencontainers/runc#1375
• setting Resources.MemorySwap unlimited after type change is messy opencontainers/runc#1421

Signed-off-by: Justin Cormack [email protected]

(cherry picked from commit e73cd70)
Signed-off-by: Tibor Vass [email protected]

From opencontainers#876

cc @justincormack @crosbymichael

[justincormack]

LGTM

…

On 6 Jul 2017 6:16 pm, "Tibor Vass" ***@***.***> wrote: The kernel ABI to these values is a string, which accepts the value -1 to mean "unlimited" or an integer up to 2^63 for an amount of memory in bytes. While the internal representation in the kernel is unsigned, this is not exposed in any ABI directly. Because of the user-kernel memory split, values over 2^63 are not really useful; indeed that much memory is not supported, as physical memory is limited to 52 bits in the forthcoming switch to five level page tables. So it is much more natural to support the value -1 for unlimited, especially as the actual number needed to represent the maximum has varied in different kernel versions, and across 32 and 64 bit architectures, so determining the value to use is not possible, so it is necessary to write the string -1 to the cgroup files. See also discussion in - opencontainers/runc#1494 <opencontainers/runc#1494> - opencontainers/runc#1492 <opencontainers/runc#1492> - opencontainers/runc#1375 <opencontainers/runc#1375> - opencontainers/runc#1421 <opencontainers/runc#1421> Signed-off-by: Justin Cormack ***@***.*** (cherry picked from commit e73cd70 <e73cd70> ) Signed-off-by: Tibor Vass ***@***.*** From opencontainers/runtime-spec#876 <opencontainers#876> cc @justincormack <https://github.com/justincormack> @crosbymichael <https://github.com/crosbymichael> ------------------------------ You can view, comment on, or merge this pull request online at: #1 Commit Summary - Make Linux memory allocations int64 not uint64 File Changes - *M* config-linux.md <https://github.com/docker/runtime-spec/pull/1/files#diff-0> (20) - *M* config.md <https://github.com/docker/runtime-spec/pull/1/files#diff-1> (4) - *M* schema/config-linux.json <https://github.com/docker/runtime-spec/pull/1/files#diff-2> (10) - *M* specs-go/config.go <https://github.com/docker/runtime-spec/pull/1/files#diff-3> (12) Patch Links: - https://github.com/docker/runtime-spec/pull/1.patch - https://github.com/docker/runtime-spec/pull/1.diff — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAdcPC5thVyi2aWfDs1MQe1q0yg13FHBks5sLRYegaJpZM4OP7su> .

[crosbymichael]

LFTM