OperatingSystemImpl should factor cpu shares when calculating system load

[Argha C]

Hello David,
It does look quite similar.
The crux is factoring in the sum of cpu time across all shares, instead of
a single cpu share.
My proposal for implementing the fix is slightly different from the PR, but
happy to trust your advice on taking this forward.


On Mon, May 3, 2021 at 3:21 PM David Holmes <david.holmes at oracle.com> wrote:

> Hi,
>
> Is this related to the issue reported here:
>
> https://bugs.openjdk.java.net/browse/JDK-8265836
>
> Cheers,
> David
>
> On 4/05/2021 3:14 am, Argha C wrote:
> > Hello,
> > I wanted to report an issue we're seeing with the load calculation, when
> > running with cpu shares > 1, in a container environment. Specifically,
> > the implementation of /OperatingSystemImpl#getCpuLoad./
> > /
> > /
> > /Problem/
> > /
> > /
> > When running with allocation of multiple cpu shares, ie. > 1 unit, the
> > load numbers do not comply with the expected range of 0-1. In the
> > example screenshot, it goes beyond 4.
> > This miscalculation throws off load based system heuristics, when
> > running in a container based environment.
> >
> > /Proposed solution/
> > /
> > /
> > In a container aware environment, for load average calculation, the
> > number of cpu cycles, ie. /getCpuPeriod /must be multiplied by the
> > number of requested cpu shares by the process, ie. /getCpuShares./
> > This would ensure that the load calculation uses the correct denominator
> > for elapsed time slice periods.
> >
> > In the screenshot below, this would mean using /getCpuShares /as a
> > multiplier for /periodLength./
> >
> > Please consider validating this behavior. I'd be happy to submit a PR
> > but I'm not an openjdk author/contributor.
> > Thanks for your consideration.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210503/691b26a7/attachment.htm>