CPU and process util stats #7420
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
amicic
force-pushed
the
cpu_and_process_stats
branch
8 times, most recently
from
bf49609
to
9824b51
Compare
amicic
force-pushed
the
cpu_and_process_stats
branch
8 times, most recently
from
22a67ae
to
275db7b
Compare
They are measured between GC STW points, excluding GC STW points themselves. They are reported at GC start point in Verbose GC as percentages, but there are also plans to use them for some future heuristics. A sample report line, showing how and where it's reported: ``` <gc-start id="190" type="scavenge" contextid="189" timestamp="2024-07-22T09:17:33.286"> <cpu-util id="191" total="80.44" process="68.95" /> <mem-info id="192" free="1438506168" total="10737418240" percent="13"> ``` Signed-off-by: Aleksandar Micic <Aleksandar_Micic@ca.ibm.com>
amicic
force-pushed
the
cpu_and_process_stats
branch
from
275db7b
to
21103f6
Compare
dmitripivkine
approved these changes
Jul 23, 2024
|
@babsingh Would you please proceed? |
|
jenkins build all |
babsingh
approved these changes
Jul 24, 2024
keithc-ca
reviewed
Jul 25, 2024
Comment on lines
+367
to
372
| <sequence maxOccurs="1" minOccurs="0"> | ||
| <element ref="vgc:cpu-util" maxOccurs="1" minOccurs="0" /> | ||
| </sequence> | ||
| <sequence maxOccurs="1" minOccurs="1"> | ||
| <element ref="vgc:mem-info" maxOccurs="1" minOccurs="0" /> | ||
| </sequence> |
There was a problem hiding this comment.
An OpenJ9 internal test (starting with build 75102) doesn't appear to like two <sequence> elements here. Perhaps this should be:
<sequence maxOccurs="1" minOccurs="0">
<element ref="vgc:cpu-util" maxOccurs="1" minOccurs="0" />
<element ref="vgc:mem-info" maxOccurs="1" minOccurs="0" />
</sequence>
amicic
pushed a commit
to amicic/omr
that referenced
this pull request
Aug 1, 2024
Seems to cause regression, and since investigation is not trivial and revert of the original change eclipse-omr#7420 would drag 3 more PRs to be reverted this is just a partial revert, that basically gets the same run-time behavior, although it does not revert some other code this will not be used/invoked. Signed-off-by: Aleksandar Micic <Aleksandar_Micic@ca.ibm.com>
amicic
pushed a commit
to amicic/omr
that referenced
this pull request
Aug 1, 2024
eclipse-omr#7420 seems to cause perf regression, and since investigation is not trivial and revert of the original change would drag 3 more PRs to be reverted this is just a partial revert, that basically gets the same run-time behavior, although it does not revert some other code this will not be used/invoked. Signed-off-by: Aleksandar Micic <Aleksandar_Micic@ca.ibm.com>
amicic
pushed a commit
to amicic/omr
that referenced
this pull request
Aug 1, 2024
eclipse-omr#7420 seems to cause perf regression, and since investigation is not trivial and revert of the original change would drag 3 more PRs to be reverted this is just a partial revert, that basically gets the same run-time behavior, although it does not revert some other code this will not be used/invoked. Signed-off-by: Aleksandar Micic <Aleksandar_Micic@ca.ibm.com>
amicic
pushed a commit
to amicic/omr
that referenced
this pull request
Aug 1, 2024
eclipse-omr#7420 seems to cause perf regression, and since investigation is not trivial and revert of the original change would drag 3 more PRs to be reverted this is just a partial revert, that basically gets the same run-time behavior, although it does not revert some other code this will not be used/invoked. Signed-off-by: Aleksandar Micic <Aleksandar_Micic@ca.ibm.com>
pshipton
pushed a commit
to pshipton/openj9-omr
that referenced
this pull request
Aug 1, 2024
eclipse-omr/omr#7420 seems to cause perf regression, and since investigation is not trivial and revert of the original change would drag 3 more PRs to be reverted this is just a partial revert, that basically gets the same run-time behavior, although it does not revert some other code this will not be used/invoked. Signed-off-by: Aleksandar Micic <Aleksandar_Micic@ca.ibm.com>
amicic
pushed a commit
to amicic/omr
that referenced
this pull request
Oct 16, 2024
eclipse-omr#7420 seems to cause perf regression, and since investigation is not trivial and revert of the original change would drag 3 more PRs to be reverted this is just a partial revert, that basically gets the same run-time behavior, although it does not revert some other code this will not be used/invoked. Signed-off-by: Aleksandar Micic <Aleksandar_Micic@ca.ibm.com>
amicic
pushed a commit
to amicic/omr
that referenced
this pull request
Oct 16, 2024
eclipse-omr#7420 seems to cause perf regression, and since investigation is not trivial and revert of the original change would drag 3 more PRs to be reverted this is just a partial revert, that basically gets the same run-time behavior, although it does not revert some other code this will not be used/invoked. Signed-off-by: Aleksandar Micic <Aleksandar_Micic@ca.ibm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
They are measured between GC STW points, excluding GC STW points
themselves. It is reported at GC start point in Verbose GC, but there
are also plans to use it for some future heuristics.
A sample report line, showing how and where it's reported: