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

Add support for reading total memory #30

Closed
wants to merge 3 commits into from

Conversation

pavolloffay
Copy link

Signed-off-by: Pavol Loffay [email protected]

Expose readings from memory.limit_in_bytes in the public API.

@CLAassistant
Copy link

CLAassistant commented Aug 24, 2020

CLA assistant check
All committers have signed the CLA.

@pavolloffay
Copy link
Author

cc @abhinav could you please review?

@codecov
Copy link

codecov bot commented Aug 24, 2020

Codecov Report

Merging #30 into master will decrease coverage by 3.79%.
The diff coverage is 52.38%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #30      +/-   ##
==========================================
- Coverage   91.91%   88.12%   -3.80%     
==========================================
  Files           8        9       +1     
  Lines         198      219      +21     
==========================================
+ Hits          182      193      +11     
- Misses         13       18       +5     
- Partials        3        8       +5     
Impacted Files Coverage Δ
internal/cgroups/cgroups.go 90.24% <50.00%> (-9.76%) ⬇️
internal/runtime/cpu_quota_linux.go 47.36% <50.00%> (+1.91%) ⬆️
totalmemory/totalmemory.go 60.00% <60.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b685be8...33c2513. Read the comment docs.

Signed-off-by: Pavol Loffay <[email protected]>
Signed-off-by: Pavol Loffay <[email protected]>
@prashantv
Copy link
Contributor

Thanks for the contribution @pavolloffay

This requires adding a new API to automaxprocs, which needs to consider the tradeoffs I've previously documented here: #29

It seems like a separate module that exposes CGroup information would be the best step forward rather than putting this logic into automaxprocs.

@pavolloffay
Copy link
Author

Thanks for the response @prashantv. Do you know a project/module where this could be done? Or do you mean creating a submodule in this project that would expose an API to read cgroups?

As the last option I can for this project and expose the read API for memory and CPU quotas.

@pavolloffay
Copy link
Author

Closing per the previous comment

@prashantv
Copy link
Contributor

I don't know what a good place for this project should be, but we don't have plans to create that project under uber-go or as part of this project. Thanks @pavolloffay

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