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

Intel RDT: updates according to proposed spec changes. #3832

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ipuustin
Copy link

There are two proposed clarifications to the OCI spec here: opencontainers/runtime-spec#1196

The first item specifies that the L3CacheSchema line filtering needs to happen only when both MemBw and L3Cache schemas are specified.

The second item specifies that the subdirectory needs to be deleted. Runc already does that, but the clarification adds for directory removal only if the directory was created by us.

@ipuustin
Copy link
Author

@marquiz

@ipuustin
Copy link
Author

ipuustin commented May 2, 2023

Rebased.

There are two proposed clarifications to the OCI spec.

The first item specifies that the L3CacheSchema line filtering needs to
happen only when both MemBw and L3Cache schemas are specified.

The second item specifies that the subdirectory needs to be deleted.
Runc already does that, but the clarification adds for directory removal
only if the directory was created by us.

Signed-off-by: Ismo Puustinen <[email protected]>
@ipuustin
Copy link
Author

ipuustin commented May 9, 2023

Rebased.

@AkihiroSuda AkihiroSuda added this to the 1.3.0 milestone May 12, 2023
@AkihiroSuda
Copy link
Member

The spec PR is not merged yet:

@kolyshkin
Copy link
Contributor

So, this one and #3833 shares some common changes. Which one do you want to go first?

if m.config.IntelRdt != nil && m.config.IntelRdt.ClosID == "" {
// There are probably other containers/tasks sharing the same group. Also
// only remove the directory if it was created by us.
if m.config.IntelRdt != nil && m.config.IntelRdt.ClosID == "" && m.directoryCreated {
m.mu.Lock()
defer m.mu.Unlock()
if err := os.RemoveAll(m.GetPath()); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not really about this PR, but this can benefit from cgroups.RemovePath, as here we only want to remove directories, not files.

Comment on lines +604 to +622
// If both l3CacheSchema and memBwSchema are set and
// 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.

validLines := make([]string, 0)

// Split the l3CacheSchema to lines.
lines := strings.Split(l3CacheSchema, "\n")

// Remove the "MB:" lines.
for _, line := range lines {
if strings.HasPrefix(line, "MB:") {
continue
}
validLines = append(validLines, line)
}

return strings.Join(validLines, "\n") + "\n" + memBwSchema
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not very efficient in terms of resources. We split the strings and then we combine them, creating two slices in the process. I'm not sure if there's a better solution (except than a slight optimization of reusing the same slice -- see https://github.com/golang/go/wiki/SliceTricks#filtering-without-allocating).

Comment on lines +604 to +607
// If both l3CacheSchema and memBwSchema are set and
// 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.
Copy link
Contributor

@kolyshkin kolyshkin May 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, can you elaborate on that requirement? In particular, why we allow a user to include MB: lines into l3CacheSchema? Would it be better to offload this requirement to a user of runc (whoever creates the OCI spec)? I mean, runc is a low level tool and should, theoretically, be as simple as possible.

My other question is -- what happens if we write both values as they are (i.e. without filtering)? Is this a security risk? Or is it just a convenience feature that allows memBwSchema to overwrite whatever is in l3CacheSchema?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One other thought. Let's say that we have

memBwSchema         = "MB:0=70;1=20"
l3CacheSchema       = "MB:0=80;1=10\nL3:0=f0;1=f"

Does it make a difference for the kernel, if we write

MB:0=80;1=10
L3:0=f0;1=f
MB:0=70;1=20

or just

L3:0=f0;1=f
MB:0=70;1=20

?

(I mean, except the additional line parsing done in the kernel)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To answer your other question: I tried this out now and having two MB values for the same domain in the same write won't work:

[root@wolfpass ipuustin]# uname -r
6.0.10-100.fc35.x86_64
[root@wolfpass ipuustin]# cat schemata-1.txt
MB:0=80;1=90
L3:0=ff;1=ff
[root@wolfpass ipuustin]# cat schemata-2.txt
MB:0=80;1=90
L3:0=ff;1=ff
MB:0=60;1=70
[root@wolfpass ipuustin]# cat schemata-1.txt > /sys/fs/resctrl/foo/schemata
[root@wolfpass ipuustin]# cat /sys/fs/resctrl/foo/schemata
    MB:0= 80;1= 90
    L3:0=0ff;1=0ff
[root@wolfpass ipuustin]# cat schemata-2.txt > /sys/fs/resctrl/foo/schemata
cat: write error: Invalid argument
[root@wolfpass ipuustin]# cat /sys/fs/resctrl/info/last_cmd_status
Duplicate domain 0

So we know that there is nobody trying to set overlapping MB: values in both memBwSchema and l3CacheSchema because that would now trigger an error in runc. There might be someone setting non-overlapping MB: values and not getting those filtered out however.

@AkihiroSuda AkihiroSuda modified the milestones: 1.3.0, 1.2.0 Jun 12, 2023
@cyphar cyphar modified the milestones: 1.2.0, 1.3.0 Oct 25, 2023
@cyphar
Copy link
Member

cyphar commented Oct 25, 2023

Moving to 1.3.0, since the spec change isn't out and we want a 1.2.0 release soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants