RFR: 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load

[Severin Gehwolf]

On Thu, 6 May 2021 02:34:01 GMT, Hao Tang <github.com+7947546+tanghaoth90 at openjdk.org> wrote:

>> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case.
>
>> Thanks for linking that. It sounds reasonable to me to prefer `quota` in that case.
> 
> Yes, flag `PreferContainerQuotaForCPUCount` is [true by default](https://github.com/openjdk/jdk/blob/739769c8/src/hotspot/os/linux/globals_linux.hpp#L62). Therefore, [my current implementation](https://github.com/openjdk/jdk/pull/3656/commits/b052b624c84) might be a minimal implementation.
> 
> We can also cover the case where `PreferContainerQuotaForCPUCount` is false. There are two different ways.
> 1. To access the value of `PreferContainerQuotaForCPUCount`, so that we can decide if we should use `quota` or (`quota` &  `share`);
> 2. Reuse `CgroupSubsystem::active_processor_count`. However, the function returns an integer. It is more reasonable to use a floating number.
> 
> Looking forward to your suggestion.

> We happened to hit an exactly similar problem when running on a container with openjdk15.
> 
> Given we effectively agree that the problem is `elapsedNanos` doesn't accurately reflect the cpu time allocated across all shares vs a single share, my proposal was to use `getCpuShares` as a multiplier for `periodLength` above.
> Is there a good reason `getCpuQuota` is a better alternative?

@argha-c  The proposed fix is within the `quota > 0` condition. I.e. this is code only run when CPU quotas, *not* shares are in effect. In docker/podman speach these are `--cpu-quota=...` and  `--cpu-period=....` switches. So no, in this case it wouldn't make sense to use cpu shares info in a branch which looks at cpu quotas ;-)

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

PR: https://git.openjdk.java.net/jdk/pull/3656