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

Deploy Intel MLC for Synthetic Memory Bandwidth Testing in CI #65

Open
yonch opened this issue Feb 18, 2025 · 1 comment
Open

Deploy Intel MLC for Synthetic Memory Bandwidth Testing in CI #65

yonch opened this issue Feb 18, 2025 · 1 comment
Labels
help wanted Extra attention is needed

Comments

@yonch
Copy link
Contributor

yonch commented Feb 18, 2025

Why: We need to validate our memory collector by generating controlled amounts of memory bandwidth interference. Intel's Memory Latency Checker (MLC) provides fine-grained control over memory bandwidth generation through command-line parameters, making it ideal for our testing infrastructure (more about this in docs).

Challenge: Intel MLC requires license acceptance for download and redistribution. We need a way to deploy it to our CI environment while respecting these license terms.

Implementation Requirements:

  1. Create a GitHub Actions workflow that:
    • Spins up an AWS EC2 instance with an ephemeral runner
    • Securely deploys Intel MLC to the instance
    • Runs configurable memory bandwidth tests
    • Collects and reports results

Key Considerations:

  • Intel MLC binary storage options:
    • Private GitHub artifact
    • Private S3 bucket accessible only to CI
  • License compliance for Intel MLC deployment

Definition of Done:

  • GitHub Actions workflow that runs synthetic memory load tests
  • Documented process for updating the Intel MLC binary
  • The MLC binary is not accessible publicly

cc @tverghis

@yonch yonch added the help wanted Extra attention is needed label Feb 18, 2025
@yonch
Copy link
Contributor Author

yonch commented Feb 26, 2025

but after working with stress-ng for a bit I think it could be a good candidate. It has a very extensive set of options (see man page). The introduction on the Ubuntu Wiki is a good start, and lists the stressor classes.

It seems that memory will try to allocate as much memory as possible until it OOMs and then starts again. For our purposes we might not want to cause as many OOMs, but rather create cache and DRAM contention. The cpu-cache might be a better stressor, and if it has a configuration for array size, we might get it to generate DRAM throughput as well.

cc @darshan-dedhia we discussed this issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant