-
Notifications
You must be signed in to change notification settings - Fork 96
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
test-configs.yaml: Enable additional preempt-rt tests #2397
base: main
Are you sure you want to change the base?
Conversation
@patersonc @aliceinwire, can CIP help out on this? |
I've created a PR to add @igaw to the list of people who's PRs get automatically included in staging tests: kernelci/kernelci-deploy#132 |
Figured out how to resolve all the dependencies to run Also, I think it would make sense to figure out if we could run a bunch of different workloads. |
Also one thing I would like to look into, is an artifact storage service like https://archive.validation.linaro.org/ so that the |
Let me know please when PR is ready for testing on staging, as it will require some adjustments for staging patches. |
fde5e66
to
1ecc7a2
Compare
@nuclearcat I am ready. I fixed all reports from |
Thanks, i will do staging run in few hours, today (need to test few more pending PR as well). |
I am sorry for delay, last time i tried to run on staging, it seems something missing on staging specific to CIP instance. (ii tried just by adding one of trees in monitor). |
FWIW, it's not just for Do you have some logs, so I can look into? |
One of errors i spotted:
|
Okay, I'll look into it. |
I'm feeling a bit stupid. |
Use a template for preempt-rt cyclictest. This is a preparation step to enable more tests from the rt-test suite. Signed-off-by: Daniel Wagner <wagi@monom.org>
Changes:
Because some of the rt-tests are CPU/board depended the last point is kind of important. I haven't looked into the different board configurations available, just assumed that the current default work fine. That is every board tested has at least 2 CPUs. |
We do currently schedule the preempt-rt tests on Beaglebone Black which is single processor, mainly just because there's lots of boards available in my lab so we can easily schedule tests there. I think it'd be fine to just not use that board so long as we've got something else providing the coverage, or to set up a nosmp variant which we select to run on single processor systems. |
I think it makes sense to keep the Beaglebone Black in the loop. I am also using this board locally for testing, so good for reproducing results locally. I haven't figured out yet how to per board type configurations are expressed. I stare a bit at the code and try to figure out what is there or to do it. |
Alternatively, I could look into extending the test suite so it automatically selects all available CPUs. In the end we are talking about |
There's not really per board configurations at the minute as far as I'm aware, modulo the tests reading things from the running system and self configuring. |
Support for automatic detection is probably going to be the easiest thing to get working here, yeah. |
BTW, I haven't changed the defaults in this PR. Thus we don't have to wait for my PR for test-definition to land first. I'll update the kernelci configuration as soon as my test-definition is available in kernelci. |
After trying to generate tests:
|
Allow to configure all parameters because these are board specific, e.g. how many CPUs are available. Thus, it doesn't make sense to hard code them. Furthermore, the various rt-tests (cyclictest, cyclicdeadline, pmqtest, ...) do have some common parameters but also unique ones. Signed-off-by: Daniel Wagner <wagi@monom.org>
Add the missing tests from the rt-tests suite. Signed-off-by: Daniel Wagner <wagi@monom.org>
While cyclictest is the classic preempt-rt test, cyclicdeadline and the rtla tests are also interesting to run. Since these are all smoke test there is no point in running them too long. Thus reduce the runtime per test to one minute. This should keep the total preempt-rt runtime roughly in the same time frame. Signed-off-by: Daniel Wagner <wagi@monom.org>
I've tried hard to get Sorry for this back and forth. I'll try to get kernelci eventually running in my own lab, so that I can test everything locally. |
plan: preempt-rt-cyclictest
job_timeout: 10
tst_cmd: 'cyclictest'
tst_group: - test:
name: preempt-rt-cyclictest
timeout:
minutes: 10
definitions:
- from: inline
repository:
metadata:
format: Lava-Test Test Definition 1.0
name: preempt-rt-prereq
description: Pre-requisites for PREEMPT_RT
run:
steps:
- apt-get update && apt-get install -y procps rt-tests
name: preempt-rt-prereq
path: inline/preempt-rt-prereq.yaml
- repository: https://github.com/kernelci/test-definitions.git
from: git
revision: kernelci.org
path: automated/linux/cyclictest/cyclictest.yaml
name: preempt-rt-cyclictest
parameters:
ARTIFACTORIAL_TOKEN:
ARTIFACTORIAL_URL:
AFFINTIY: 0-1
DURATION: 300s
BACKGROUND_CMD: hackbench
HISTOGRAM:
INTERVAL: 1000
PRIORITY: 98
THREADS: 2 |
The PR for LAVA has been merged. I am not really familiar how the LAVA test suite is intergrated into kernel-ci. Does it always run against the latest version or is there some sort of sync involved. Just asking if I should update this PR to use the new feature which lets cyclictest run on all CPUs and not just two. |
@nuclearcat I've update the series and it's ready for the integration test. I really hope i got it right this time |
@nuclearcat friendly ping. |
Is there anything I can do to get this moving? |
While cyclictest is the classic preempt-rt test, cyclicdeadline and the rtla tests are also interesting to run.
Since these are all smoke test there is no point in running them too long. Thus reduce the runtime per test to one minute. This should keep the total preempt-rt runtime roughly in the same time frame.