config-linux: clarify the handling of ClosID RDT parameter#1104
config-linux: clarify the handling of ClosID RDT parameter#1104vbatts merged 2 commits intoopencontainers:masterfrom
Conversation
marquiz
commented
Apr 26, 2021
marquiz
commented
- An attempt to make the spec easier to interpret by grouping all ClosID related contraints in one place.
- fix indentation on IntelRdt, and split out the rules regarding interdependency of parameters into a separate list.
Also, split out the rules regarding interdependency of parameters into a separate list. Signed-off-by: Markus Lehtonen <[email protected]>
An attempt to make the spec easier to interpret by grouping all ClosID related contraints in one place. Signed-off-by: Markus Lehtonen <[email protected]>
| * If `closID` is set, and neither of `l3CacheSchema` and `memBwSchema` are set, runtime MUST check if corresponding pre-configured directory `closID` is present in mounted `resctrl`. If such pre-configured directory `closID` exists, runtime MUST assign container to this `closID` and [generate an error](runtime.md#errors) if directory does not exist. | ||
| * If `closID` is set, `l3CacheSchema` and/or `memBwSchema` is set, runtimes MUST compare `l3CacheSchema` and/or `memBwSchema` value with `schemata` file, and [generate an error](runtime.md#errors) if doesn't match. | ||
|
|
||
| * If `closID` is set, and neither of `l3CacheSchema` and `memBwSchema` are set, runtime MUST check if corresponding pre-configured directory `closID` is present in mounted `resctrl`. If such pre-configured directory `closID` exists, runtime MUST assign container to this `closID` and [generate an error](runtime.md#errors) if directory does not exist. |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
Ah, you do this in the second commit. Nice!
|
Thanks for the review @kolyshkin! Is there somebody I should assign this to or smth else to do except for sit and wait? 😄 |
|
ping |
|
LGTM. Making use of pre-configured ClosIDs is a good improvement, it helps prevent running out of hardware CLOSIDs in container user scenarios. The number of CLOSIDs have a hardware limit which is exposed by kernel resctrl filesystem, and is also exposed by runc events command (GetStats): |
|
ping @crosbymichael could this be merged? |
|
Thanks @vbatts 🚀 😄 |
| * If both `l3CacheSchema` and `memBwSchema` are set, runtimes MUST write the combined value to the `schemata` file in that sub-directory discussed in `closID`. | ||
|
|
||
| * If either `l3CacheSchema` or `memBwSchema` is set, runtimes MUST write the value to the `schemata` file in the that sub-directory discussed in `closID`. | ||
| * If `l3CacheSchema` contains a line beginning with `MB:`, the value written to `schemata` file MUST be the non-`MB:` line(s) from `l3CacheSchema` and the line from `memBWSchema`. |
There was a problem hiding this comment.
@marquiz I am looking at the specs to implement this in crun but I don't understand this rule.
Can you give an example? Should it be dropped (at least I don't see any special handling in runc either for this)?
There was a problem hiding this comment.
@giuseppe the idea is that if you have
l3CacheSchema: "L3:foobar\nMB:abcd"
memBWSchema: "MB:xyzy"
Then you'd actually write L3:foobar\nMB:xyzy to the schemata file.
I don't think this has been implemented anywhere. I didn't write this particular formulation, and TBH, I wouldn't probably bother implementing it. I think the fields and there handling is just ambiguously specified, e.g. somehow it's implied that l3CacheSchema could contain multiple lines but memBWSchema only one line. What if l3CacheSchema contains L3:... but memBWSchema: contains L3:... (and other similar questions)...
I try to address the problems in #1230
There was a problem hiding this comment.
thanks, I understand now. Still feels weird to specify that MB: is filtered out instead of just not expecting such a case :-) but I guess we can live with it at this point
7 participants
