RFR: 8230305: Cgroups v2: Container awareness
Severin Gehwolf
sgehwolf at redhat.com
Fri Nov 8 14:21:05 UTC 2019
Hi Bob,
On Wed, 2019-11-06 at 10:47 +0100, Severin Gehwolf wrote:
> On Tue, 2019-11-05 at 16:54 -0500, Bob Vandette wrote:
> > Severin,
> >
> > Thanks for taking on this cgroup v2 improvement.
> >
> > In general I like the implementation and the refactoring. The CachedMetric class is nice.
> > We can add any metric we want to cache in a more general way.
> >
> > Is this the latest version of the webrev?
> >
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/cgroupsv2-hotspot/03/webrev/src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp.html
> >
> > It looks like you need to add the caching support for active_processor_count (JDK-8227006).
>
[...]
> I'll do a proper rebase ASAP.
Latest webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/cgroupsv2-hotspot/05/webrev/
> > I’m not sure it’s worth providing different strings for Unlimited versus Max or Scaled shares.
> > I’d just try to be compatible with the cgroupv2 output so you don’t have to change the test.
>
> OK. Will do.
Unfortunately, there is no way of NOT changing TestCPUAwareness.java as
it expects CPU Shares to be written to the cgroup filesystem verbatim.
That's no longer the case for cgroups v2 (at least for crun). Either
way, most test changes are gone now.
> > I wonder if it’s worth trying to synthesize memory_max_usage_in_bytes() by keeping the highest
> > value ever returned by the API.
>
> Interesting idea. I'll ponder this a bit and get back to you.
This has been implemented. I'm not sure this is correct, though. It
merely piggy-backs on calls to memory_usage_in_bytes() and keeps the
high watermark value of that.
Testing passed on F31 with cgroups v2 controllers properly configured
(podman) and hybrid (legacy hierarchy) with docker/podman.
Thoughts?
Thanks,
Severin
More information about the hotspot-dev
mailing list