Use uint64 for resources to keep consistency with runtime-spec #1375
+63
−62
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Qiang Huang <[email protected]>
|
256/264 passed on RHEL - Failed. |
|
LGTM |
1 similar comment
|
LGTM |
This was referenced Apr 26, 2017
|
This breaks use of the value |
|
@justincormack do you want to submit a PR to revert this? |
|
@justincormack |
This was referenced Jun 23, 2017
justincormack
added a commit
to justincormack/runtime-spec
that referenced
this pull request
Jun 23, 2017
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#1492 - opencontainers/runc#1375 - opencontainers/runc#1421 Signed-off-by: Justin Cormack <[email protected]>
justincormack
added a commit
to justincormack/runtime-spec
that referenced
this pull request
Jun 23, 2017
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#1492 - opencontainers/runc#1375 - opencontainers/runc#1421 Signed-off-by: Justin Cormack <[email protected]>
justincormack
added a commit
to justincormack/runtime-spec
that referenced
this pull request
Jun 23, 2017
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#1492 - opencontainers/runc#1375 - opencontainers/runc#1421 Signed-off-by: Justin Cormack <[email protected]>
justincormack
added a commit
to justincormack/runtime-spec
that referenced
this pull request
Jun 23, 2017
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#1492 - opencontainers/runc#1375 - opencontainers/runc#1421 Signed-off-by: Justin Cormack <[email protected]>
tiborvass
pushed a commit
to tiborvass/runtime-spec
that referenced
this pull request
Jul 6, 2017
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#1492 - opencontainers/runc#1375 - opencontainers/runc#1421 Signed-off-by: Justin Cormack <[email protected]> (cherry picked from commit e73cd70) Signed-off-by: Tibor Vass <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Signed-off-by: Qiang Huang [email protected]