On Thu, 6 May 2021 02:34:01 GMT, Hao Tang <github.com+7947546+tanghaot...@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
