[jdk8u-dev] RFR: 8230305: Cgroups v2: Container awareness [v2]

[Severin Gehwolf]

On Mon, 31 Oct 2022 11:30:24 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

>> hotspot/src/os/linux/vm/cgroupSubsystem_linux.cpp line 447:
>> 
>> 
>> This is actually code added with [JDK-8232207](https://bugs.openjdk.org/browse/JDK-8232207) which shouldn't affect JDK 8. So I'm not sure about this. Add it to 8u anyway (and have less divergence) or remove and deal with the code difference.
>> 
>> Whatever the way, we need to make this clear by: a) adding the issue using `/issue add` or b) restructuring this code to account for it. I'm slightly in favor of b).
>
> I tried a very basic JMH bench with/without the memory caching in place and it had no obvious impact one way or another, but I'm leaning towards a) because removing it means re-working quite a few bits, including switching _memory from a CachingCgroupController to CgroupController (or CgroupV1Controller etc) so the macros GET_CONTAINER_INFO and friends still work. The deltas will be across at least four source files.

Thanks. My thinking was for b) to use a patch like:


commit 9546da23b777625cb2bdd397080dae280e91b854 (HEAD -> pull/127-rebased)
Author: Severin Gehwolf <sgehwolf at redhat.com>
Date:   Thu Nov 3 19:55:20 2022 +0100

    Only cache CPU metrics

diff --git a/hotspot/src/os/linux/vm/cgroupSubsystem_linux.cpp b/hotspot/src/os/linux/vm/cgroupSubsystem_linux.cpp
index b93c8b308b..923ad7838a 100644
--- a/hotspot/src/os/linux/vm/cgroupSubsystem_linux.cpp
+++ b/hotspot/src/os/linux/vm/cgroupSubsystem_linux.cpp
@@ -440,13 +440,6 @@ int CgroupSubsystem::active_processor_count() {
  *    OSCONTAINER_ERROR for not supported
  */
 jlong CgroupSubsystem::memory_limit_in_bytes() {
-  CachingCgroupController* contrl = memory_controller();
-  CachedMetric* memory_limit = contrl->metrics_cache();
-  if (!memory_limit->should_check_metric()) {
-    return memory_limit->value();
-  }
   jlong mem_limit = read_memory_limit_in_bytes();
-  // Update cached metric to avoid re-reading container settings too often
-  memory_limit->set_value(mem_limit, OSCONTAINER_CACHE_TIMEOUT);
   return mem_limit;
 }


But my basic experiments don't suggest this makes a whole lot of difference. Given that `available_memory()` is being used in `hotspot/src/share/vm/jfr/periodic/jfrPeriodic.cpp` for the physical memory event, I'm OK with leaving it in as it might be beneficial for the JFR tracing. If that turns out to be a problem, we can revisit this later. OK with keeping it as is.

-------------

PR: https://git.openjdk.org/jdk8u-dev/pull/127