-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-enable cgroup test for s390x #189
Comments
This was fixed in mono with dotnet/runtime#74237 and should be a part of 7.0 now. This test is now expected to pass on 7.0 for mono runtimes too. |
I have run this test on ppc64le and s390x now and both fail: s390x
ppc64le
@tmds @uweigand @janani66 Does this seem expected? Any idea what's going on? Is it a test bug or a bug in mono? |
means If you vary the |
@tmds Well changing the MemoryLimit doesn't seem to change anything on ppc64le running .NET7 RC2 code [cgroup-limit]#systemd-run -q --scope -p CPUQuota=100% -p MemoryLimit=250M bin/Debug/net7.0/cgroup-limit [cgroup-limit]#systemd-run -q --scope -p CPUQuota=100% -p MemoryLimit=200M bin/Debug/net7.0/cgroup-limit [cgroup-limit]#systemd-run -q --scope -p CPUQuota=100% -p MemoryLimit=100M bin/Debug/net7.0/cgroup-limit |
BTW, I am testing with .NET7.0 RC2 which has: But it does not have: |
@omajid this is not a blocker for 7.0, right? |
Hmm. Looking at the sources, I see:
However, the variable
So I believe the intent was to allow using "75% of the container limit, but at least 20MB" - but the code actually does "75% of the container limit, but at least 200MB". This seems to match the measurements above. @janani66 can you try larger values? E.g. with 300MB container limit, you should be seeing more than 200MB. @nealef, I'm assuming the comment is correct and this should really be 20MB instead of 200MB? I cannot find either limit in the CoreCLR implementation at first glance, so I'm not sure where these values come from ... |
@omajid if changing the |
@uweigand -- you nailed it [root@ltcden12-lp6 cgroup-limit]# systemd-run -q --scope -p CPUQuota=100% -p MemoryLimit=300M bin/Debug/net7.0/cgroup-limit |
IMO, It's not a blocker. Most importantly, it's not a regression. It only affects mono (where cgroup was previously compleletey broken). If we have a fix, we can take it, or we can wait for a fix to flow in through a monthly servicing update.
Yes. We don't have the final builds GA yet so we have some time to tweak things. Since this only affects mono, if you and @janani66 agree on a fix, We can include it. It would be nice to send a PR to dotnet/runtime for 7.0 though (for review/sanity-check and reduce our maintenance burden down the road). |
I've now found the corresponding place in CoreCLR, and it is indeed using 20 MB, not 200 MB. See the comment here:
The attached patch implements the obvious fix to change to 20 MB in Mono as well: @nealef given that this is originally your implementation, could you move that forward as PRs in all affected branches as well? Thanks! |
Will do. The irony is I had coded it as 20 *1024*1024 but was told I should use a #define and then incorrectly calculated the value instead of leaving it in that form.
…-------- Original message --------
From: Ulrich Weigand ***@***.***>
Date: 10/28/22 10:27 (GMT-05:00)
To: redhat-developer/dotnet-regular-tests ***@***.***>
Cc: Neale Ferguson ***@***.***>, Mention ***@***.***>
Subject: Re: [redhat-developer/dotnet-regular-tests] Re-enable cgroup test for s390x (Issue #189)
I've now found the corresponding place in CoreCLR, and it is indeed using 20 MB, not 200 MB. See the comment here:
https://github.com/dotnet/runtime/blob/a6f4527ebf2c3faa5b9f55e8a7acb12df4571425/src/coreclr/gc/gcpriv.h#L4062-L4067
and the implementation at around line 45176 in src/coreclr/gc/gc.cpp:
// If the hard limit is specified, the user is saying even if the process is already
// running in a container, use this limit for the GC heap.
if (gc_heap::heap_hard_limit)
{
#ifdef FEATURE_EVENT_TRACE
gc_heap::hard_limit_config_p = true;
#endif //FEATURE_EVENT_TRACE
}
else
{
if (gc_heap::is_restricted_physical_mem)
{
uint64_t physical_mem_for_gc = gc_heap::total_physical_mem * (uint64_t)75 / (uint64_t)100;
gc_heap::heap_hard_limit = (size_t)max ((20 * 1024 * 1024), physical_mem_for_gc);
}
}
The attached patch implements the obvious fix to change to 20 MB in Mono as well:
mono-cgroup-minmemsz-fix.txt<https://github.com/redhat-developer/dotnet-regular-tests/files/9889185/mono-cgroup-minmemsz-fix.txt>
@nealef<https://github.com/nealef> given that this is originally your implementation, could you move that forward as PRs in all affected branches as well? Thanks!
—
Reply to this email directly, view it on GitHub<#189 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AACLN6WGKRAN2C5EBPLLJCLWFPPDRANCNFSM5OA72ETA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
PRs generated - |
I have been able to verify the fix in the runtime repo [root@kop5 cgroup-limit]# systemd-run -q --scope -p CPUQuota=100% -p MemoryLimit=200M bin/Debug/net7.0/cgroup-limit |
Cgroup support is currently not implemented on mono (used on s390x). We are going to, shortly, disable that test on s390x.
But upstream is working on a fix, we should enable the test for s390x when mono gets support for cgroups.
The text was updated successfully, but these errors were encountered: