According to our practical testing, the --oom-kill-disable flag doesn't work at all on AArch64 (actually I believe it doesn't on other Arches). We manually spawn a memory-consuming docker instance with runc run with below spec nit:

"linux": {
                "resources": {
                        "memory": {
                                "limit": 10485760,
                                "disableOOMKiller": false
                        },
                        "devices": [
                                {
                                        "allow": false,
                                        "access": "rwm"
                                }
                        ]
                },

That works for the oom-kill feature, so the root cause should be the docker daemon doesn't pass correct oom-kill related field to the runc. Now we suggest to skip this test on AArch64, but if community does need to make this feature work as expected, we can work on to fix it. But before we take any action to do that, it's important for us to get some suggests/comments from the maintainers 👍

Curious, what exactly is it failing with? This test was skipped on arm32 because it was failing, but I don't think anyone ever looked at it #19412

I'll add that the flag works correctly with both docker and runc on ppc64le, so it might be something specific arm specific.

@tophj-ibm Although this issue is triggered by AArch64 platform, but after some investigation, we found that it's not Arch-specific, we have an initial fixing solution for this issue in PR #36201. Interesting all the arches (amd64, s390, ppc...) have skipped this test, I don't know the context/story here... 🤕

You're correct. I was testing with docker-ee which oddly doesn't have this isssue. Building from upstream however, I did encounter it (and saw it was fixed by your PR)!

Ah, You remind me to test with 17.12.0-ce, the issue is there, but I haven't docker-ee version at hand now...
IMO this PR can be closed if PR #36201 merged 💯

Let’s close this in favor of #36201, which looks like the correct fix (thanks!)