topology-aware: implement strict hint and CPU isolation preferences.#638
topology-aware: implement strict hint and CPU isolation preferences.#638klihub wants to merge 7 commits intocontainers:mainfrom
Conversation
Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Add support for annotating a container to be subject to strict topology hint interpretation. The creation of such a container should ideally fail if any topology hints cannot be satisfied. In addition to this, add support for injecting topology hints into containers by annotation for testing purposes. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Implement strict interpretation of topology hints. Fail container creation if any hints are unsatisfied when a container is marked for strict hints. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
klihub
force-pushed
the
devel/strict-alignment
branch
2 times, most recently
from
1ee2f47 to
6c430a6
Compare
klihub
force-pushed
the
devel/strict-alignment
branch
from
6c430a6 to
8b8555d
Compare
| report allowed | ||
| verify \ | ||
| 'cpus["pod5c0"].issubset({"cpu08", "cpu09", "cpu10", "cpu11"})' \ | ||
| 'node_ids(nodes["pod5c0"]) == {2}' |
There was a problem hiding this comment.
Do you think we could have a prefer-isolated-cpus test step, too, without require-isolated-cpus present in the same pod?
There was a problem hiding this comment.
Yes, based on the existing bugs in the code, it is more than warranted to add test cases to verify correct semantics for the coexistence of both keys in the annotations.
There was a problem hiding this comment.
Actually I think what we really need to test is the semantics of co-existence of those two annotations, but at different (pod vs. container) scopes.
And I think we should start considering for future preference annotations how the current syntax for a base key could be extended, in addition to the current scoping, with preference vs. requirement semantics or other semantics, probably using as a prefix to the key.
So something like
key=$key
preference: prefer.$key/$scope
requirement: require.$key/$scope
Then this would become:
prefer.isolated-cpus/pod: "true"
require.isolated-cpus/container.ctr0: "true"
prefer.shared-cpus/container.ctr1: "true"
And a querying function, which return all of the nuances related to the semantics of a key which supports semantic prefixing.
Such a scheme would also force us to be more consistent with the annotations.
There was a problem hiding this comment.
Anyway, upated adding more test checking correctness of the interpretation of multiple coexisting keys.
There was a problem hiding this comment.
Let me know if you think more tests/combinations are warranted.
Add pod/container QueryEffectiveAnnotation() which, in addition to any effective annotation found, also return the scope at which the annotation was found. This can help implementing correct semantics when multiple possible annotations might be in effect for the same functionality. For instance one key indicating a soft and another a strict preference and they are given with different scopes. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Implement strictly required preference for isolated CPUs using the new `require-isolated-cpus` annotation key. Fail container creation if a strict preference is unsatisfied. Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
klihub
force-pushed
the
devel/strict-alignment
branch
from
8b8555d to
a985c22
Compare
Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
klihub
force-pushed
the
devel/strict-alignment
branch
from
a985c22 to
86b2a5c
Compare
2 participants
This patch series adds