Skip to content

Latest commit

 

History

History
62 lines (49 loc) · 2.22 KB

cyclictest.md

File metadata and controls

62 lines (49 loc) · 2.22 KB

cyclictest

cyclictest is a performance testing tool for real-time kernels, that helps us qunatify latencies. Latency is the time between the occurence of an event (like an interrupt) and the time that the event is handled. Cyclictest measures the amount of time that passes between when a timer expires and when the thread which set the timer actually runs, thereby helping us quantiy latencies.

The goal of the cyclictest workload in the benchmark-operator is to run cyclictest inside of a container and measure the latency per core. This is done by running one SCHED_FIFO thread per core. The workload also gives the option to run [stress-ng] to rum some SCHED_OTHER tasks along with SCHED_FIFO real-time tasks which are higher priority.

Running cyclictest

Given that you followed instructions to deploy operator, you can modify cr.yaml to your needs. It is recommended to define pod requests and limits when running cyclict test, to give guaranteed CPUs to the pods. It is also expected to have the realtime kernel installed with required isolation for pods using the Performance Add-On Operator.

An example CR might look like this

apiVersion: ripsaw.cloudbulldozer.io/v1alpha1
kind: Benchmark
metadata:
  name: cyclictest
  namespace: benchmark-operator
spec:
  elasticsearch:
    server: <ES_SERVER>
  workload:
    name: "cyclictest"
    args:
      node_selector: "<nodeSelector for the RT worker>"
      duration: "1m"
      disable_cpu_balance: true
      stressng: false
      pod:
        requests:
          memory: "200Mi"
          cpu: "4"
        limits:
          memory: "200Mi"
          cpu: "4"

You can run it by:

# kubectl apply -f config/samples/cyclictest/cr.yaml # if edited the original one
# kubectl apply -f <path_to_file> # if created a new cr file

Looking at results

You can look at the results from the cyclictest benchmark by doing

NAME=cyclictest-workload-xxxxxxx
oc logs -n benchmark-operator $NAME

Cleanup

When you're done simply delete the benchmark CR; the job and its pod will be garbage-collected automatically.