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

libctr/fs2: Initialize MaxUsage field with memory.peak value #4038

Closed
wants to merge 1 commit into from

Conversation

haircommander
Copy link
Contributor

as well as rework the function to reduce duplication, and update the test for it

// Ignore EEXIST as there's no swap accounting
// if kernel CONFIG_MEMCG_SWAP is not set or
// swapaccount=0 kernel boot parameter is given.
return cgroups.MemoryData{}, nil
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think this line should be questioned. I think it'd be better if we continued to collect if there was an error and returned whatever we found at the end

Copy link
Contributor

Choose a reason for hiding this comment

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

Not quite. This is for case of name == "swap" (which is implicit here), meaning we're trying to read memory.swap.* values -- and they all are either present or not, so we bail out early when getting ENOENT from open("memory.swap.current").

OTOH if *.peak counter is optional, the logic should be changed. Is it?

While at it, we can always return memoryData not cgroups.MemoryData.

(BTW I took a look at CONFIG_MEMCG_SWAP and it was dropped from Linux v6.1, but there's still CONFIG_SWAP)

Copy link
Contributor

Choose a reason for hiding this comment

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

Not quite. This is for case of name == "swap" (which is implicit here), meaning we're trying to read memory.swap.* values -- and they all are either present or not, so we bail out early when getting ENOENT from open("memory.swap.current").

Meaning, I'd drop the second commit in this PR (and maybe add a better comment explaining why we're bailing out early).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

*peak is added in kernel 5.14--so not yet in any el variants (it's being backported to centos 9 now) which is why I think the second commit is the correct behavior

Copy link
Contributor

Choose a reason for hiding this comment

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

For peak, yes. So it should be like this:

  • if memory.swap.current is not available, return empty set and no error (that's what the current code does);
  • if *.peak is not available, return what we have collected so far.

Copy link
Contributor

Choose a reason for hiding this comment

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

So, maybe something like this

if err != nil {
   if os.IsNotExist(err) {
      // Swap accounting is optional, so return early if absent.
      if name == "swap" {
         err = nil
      }
      // Peak usage is only available since kernel v5.14.
      if strings.HasSuffix(v.name, "peak") {
         err = nil
      }
     return memoryData, err
   }
}

(plus add a comment above saying the order is important)

Copy link
Contributor

Choose a reason for hiding this comment

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

Or, for better readability,

-      if name == "swap" { 
+      if name == "swap" { // memory.swap.current not found.

or even

-      if name == "swap" { 
+      if f.name == "memory.swap.current" {

@lifubang
Copy link
Member

Total memory max usage != memory.peak + memory.swap.peak
#4010 (comment)

as well as rework the function to reduce duplication, and update the test for it

Signed-off-by: Peter Hunt <[email protected]>
@haircommander
Copy link
Contributor Author

I didn't notice #4010! convo is more developed over there, so I can close this in favor of that

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.

3 participants