Shailend ChandandgVisor bot
a43cece85a
The cpu controller tracks each task's CPU via a per-instance baseline
snapshot plus a cumulative total for exited tasks, but it never walked
the whole accounting domain when reporting cpu.stat and never reconciled
that state when a controller was disabled or when a task migrated within
a single controller's domain. This caused three accounting errors, each
covered by a new test:
- Live tasks in descendant cgroups that had not enabled their own cpu
controller were absent from the ancestor's cpu.stat until they
exited, even though Linux aggregates descendant usage into the
ancestor continuously.
- Migrating a task between two cgroups sharing the same nearest cpu
controller reset its baseline, discarding the pre-migration CPU.
- Disabling +cpu discarded the controller's accumulated usage instead
of reparenting it (Linux folds an offlined css's stats into parent).
Sum the whole domain (the controller's cgroup plus every descendant
without its own cpu controller, recursing into descendants that do) when
reading cpu.stat; leave the baseline untouched on same-instance
migration; and on disable, migrate the domain's tasks to the parent's
nearest cpu controller and fold the accumulated total into it.
PiperOrigin-RevId: 974821312
Tests
The tests defined under this path are verifying functionality beyond what unit tests can cover, e.g. integration and end to end tests. Due to their nature, they may need extra setup in the test machine and extra configuration to run.
- syscalls: system call tests use a local runner, and do not require additional configuration in the machine.
- integration: defines integration tests that uses
docker runto test functionality. - image: basic end to end test for popular images. These require the same setup as integration tests.
- root: tests that require to be run as root. These require the same setup as integration tests.
- util: utilities library to support the tests.
For the above noted cases, the relevant runtime must be installed via runsc install before running. Just note that they require specific configuration to
work. This is handled automatically by the test scripts in the scripts
directory and they can be used to run tests locally on your machine. They are
also used to run these tests in kokoro.
Example:
To run image and integration tests, run:
make docker-tests
To run root tests, run:
make sudo TARGETS=test/root:root_test
There are a few other interesting variations for image and integration tests:
- overlay: sets writable overlay inside the sentry
- hostnet: configures host network passthrough, instead of netstack
- kvm: runsc the test using the KVM platform, instead of systrap
The test will build runsc, configure it with your local docker, restart
dockerd, and run tests. The location for runsc logs is printed to the output.