Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[rteval] Add initial rteval support #19

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

wchwhite
Copy link
Contributor

@wchwhite wchwhite commented Oct 26, 2023

Description:
This PR introduces support for rteval in our tooling. The new integration brings in several configuration options to provide flexibility for different tracing and performance measurement scenarios.

Key Features:

CPU Configuration: Set specific CPUs for LOAD and MEASUREMENT purposes.
Threshold Settings: Users can define a custom threshold, defaulting to 150.
Breakpoint Support: Introduces SET_BREAK for integrating with other tracing tools.
Trace Collection: Using TRACE_CMD, users can collect trace data which will be stored in logs.
Event List Management: A default event list for tracing is set, but users have the option to provide a custom list.
Load Generation: Using ONLYLOADS, external tools can measure generated loads.
Report Collection: GEN_REPORT facilitates the collection of sosreports, which are subsequently stored in logs.
Extras:

Sample YAML configurations have been added, catering to scenarios like load generation, tracing with trace-cmd, and standard operations.

This commit introduces initial rteval support with these options:
- LOAD_CPUS and MEASUREMENT_CPUS can be set. Defaults to no use.
- THRESHOLD can be set and defaults to 150.
- SET_BREAK can be set to create a breakpoint for other tracing tools.
- TRACE_CMD can be set to collect a trace.dat, which is stored to logs.
- Sets a default EVENTS list for tracing but allows a custom list to be entered.
- ONLYLOADS can be used to generate loads for another tool to measure.
- GEN_REPORT can be used to collect sosreports, which is copied to the logs.

Additionally, sample yamls have been generated for load generation, trace-cmd,
and normal operation.

Signed-off-by: Chris White <[email protected]>
@@ -0,0 +1,13 @@
# Based on centos:stream9 as per your requirement
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change comment to:
Based on centos:stream9 to allow for building without a Red Hat subscription


# if tracing is enabled, disable some things that may get in the way
if [[ "$TRACE_CMD" == "y" || "$SET_BREAK" == "y" ]]; then
# If setting a break point for another tool to use, disable reprot generation so it does not intefer.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: spelling "reprot" and "interfer"

restartPolicy: Never
containers:
- name: rteval
image: qquay.io/container-perf-tools/rteval
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Image is incorrect - make sure you test each of your yamls.

Comment on lines +17 to +18
- name: tool
value: "rteval"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tool env variable is not being used.

spec:
runtimeClassName: performance-openshift-node-performance-profile
restartPolicy: Never
containers:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are no cpu/memory resources specified for this container, which means it will float across all the application CPUs. Is that what you want? If so, then this is not a guaranteed QoS pod and the annotations you specified will have no effect so should be deleted.

Comment on lines +20 to +21
- name: LOAD_CPUS
value: "0"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CPU 0 is going to be one of the reserved platform CPUs. Do you want to run the load there? Also, in kubernetes you do not have control over which CPUs the pod is going to run on. Would it be better to create a guaranteed QoS pod and then just specify the number of LOAD_CPUS and have the cmd.sh script allocate that number of CPUs from the set that are assigned to the pod at creation time?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants