[PING!] RFR: 8230305: Cgroups v2: Container awareness

[Severin Gehwolf]

On Fri, 2019-11-08 at 15:21 +0100, Severin Gehwolf wrote:
> 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?

Ping?

Metrics work proposed for RFR here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063464.html

Thanks,
Severin