RFR [14]: 8232207: Linux os::available_memory re-reads cgroup configuration on every invocation
Claes Redestad
claes.redestad at oracle.com
Tue Oct 15 14:59:27 UTC 2019
Hi Severin,
On 2019-10-15 16:33, Severin Gehwolf wrote:
> Hi Claes,
>
> On Tue, 2019-10-15 at 11:12 +0200, Claes Redestad wrote:
>> Hi,
>>
>> on a Linux system with container support, os::available_memory will read
>> cgroup configuration files from /proc to determine max memory limits.
>> This leads to measurable memory overheads in some places, e.g., JIT
>> compiler threads will poll os::available_memory between compilation to
>> determine if we need to reduce the number of compiler threads.
>>
>> Overhead from polling these /proc files can take up to 5% of total CPU
>> resource usage during startup and warmup.
>
> Would there be a way to reproduce this myself? What did you use to
> measure this? It would come in handy for the cgroups v2 work I'm doing.
It should be reproducible on most Linuxes - within or outside docker -
when the kernel is built with CONFIG_SCHED_AUTOGROUP=y (which is the
case on all my machines, apparently..)
I run various startup tests wrapped by perf stat, for example:
perf stat -r 50 java Hello World
>
> How does this compare to -XX:-UseContainerSupport runs?
-XX:-UseContainerSupport recuperates a few more cycles, e.g.:
120,105,173 instructions # 0.83 insns per
cycle ( +- 0.08% )
23,843,560 branches # 433.858 M/sec
( +- 0.08% )
822,607 branch-misses # 3.45% of all
branches ( +- 0.22% )
0.037818060 seconds time elapsed
( +- 0.38% )
So there's a very small cost you can avoid by turning off container
support.
>
> Aside: It seems we'd need similar work for
> OSContainer::active_processor_count(). Or rather, cpu_quota(),
> cpu_period() and cpu_shares() functions. See:
>
> https://bugs.openjdk.java.net/browse/JDK-8227006
>
> I'll give using a similar approach for active_processor_count() a shot.
Could be worthwhile, but the reason we see an improvement here is that
we avoid a situation where many (compiler) threads are concurrently
querying for the current setting during a short time frame. Each call
(outside of the grace time) is still just as expensive. So it'd be nice
with a faster API..
Thanks!
/Claes
More information about the hotspot-runtime-dev
mailing list