Container: Do not set "soft" limit when hard limit is set for cgroupv2 #13192
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
…is set In cgroup-v1 memcg implementation we have a concept of "soft" memory limit (`memory.soft_limit_in_bytes`). In cgroup-v2 memcg we don't have an explicit analog of it. Originally, when hard memory limit is set, we set it value to `memory.limit_in_bytes` and set 90% of its value to `memory.soft_limit_in_bytes`. And it was working quite well. But in cgroup-v2 we tried to treat `memory.high` as analogy to `memory.soft_limit_in_bytes` which is not fully correct. Yes, reaching `memory.high` limit does not invoke OOM-killer, at the same time it forces process to go into memory reclaim on each page fault that want's to charge pages in memcg which makes its execution terribly slow. Let's stop doing that. If hard limit is set, let's set only `memory.max` value and do nothing with `memory.high`. But if soft limit is set, then we have not so many options and let's stick with setting `memory.high` value. Fixes: canonical#13147 Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
|
@mihalicyn how hard would it be to add tests for that? Our GHA runners are all cgroup2 ready. |
|
yeah we should add a test |
mihalicyn
added a commit
to mihalicyn/lxd-ci
that referenced
this pull request
Mar 21, 2024
canonical/lxd#13192 Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
mihalicyn
added a commit
to mihalicyn/lxd-ci
that referenced
this pull request
Mar 21, 2024
canonical/lxd#13192 Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
mihalicyn
added a commit
to mihalicyn/lxd-ci
that referenced
this pull request
Mar 21, 2024
canonical/lxd#13192 Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
mihalicyn
added a commit
to mihalicyn/lxd-ci
that referenced
this pull request
Mar 21, 2024
canonical/lxd#13192 Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Test is ready canonical/lxd-ci#107 ;-) |
tomponline
changed the title
mihalicyn
added a commit
to mihalicyn/lxd-ci
that referenced
this pull request
Mar 22, 2024
canonical/lxd#13192 Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
mihalicyn
added a commit
to mihalicyn/lxd-ci
that referenced
this pull request
Mar 22, 2024
canonical/lxd#13192 Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
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.
In cgroup-v1 memcg implementation we have a concept of "soft" memory limit (
memory.soft_limit_in_bytes). In cgroup-v2 memcg we don't have an explicit analog of it. Originally, when hard memory limit is set, we set it value tomemory.limit_in_bytesand set 90% of its value tomemory.soft_limit_in_bytes. And it was working quite well. But in cgroup-v2 we tried to treatmemory.highas analogy tomemory.soft_limit_in_byteswhich is not fully correct. Yes, reachingmemory.highlimit does not invoke OOM-killer, at the same time it forces process to go into memory reclaim on each page fault that want's to charge pages in memcg which makes its execution terribly slow. Let's stop doing that. If hard limit is set, let's set onlymemory.maxvalue and do nothing withmemory.high. But if soft limit is set, then we have not so many options and let's stick with settingmemory.highvalue.Fixes: #13147