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

begin work of supporting current resource usage #358

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

Conversation

jaypipes
Copy link
Owner

This patch begins the process of supporting current resource usage information in ghw. The first resource we support is memory on Linux systems.

Users can use the ghw.WithCollectUsage(true) function to instruct ghw to gather usage information for the module in question. Alternately, users can use the GHW_COLLECT_USAGE=1 environs variable. The following shows the effect of the variable:

jaypipes@lappie:~/src/github.com/jaypipes/ghw$ go run cmd/ghwc/main.go memory
memory (16GB physical, 16GB usable)
jaypipes@lappie:~/src/github.com/jaypipes/ghw$ GHW_COLLECT_USAGE=1 go run cmd/ghwc/main.go memory
memory (16GB physical, 16GB usable, 9GB used)

Issue #357

This patch begins the process of supporting current resource usage
information in `ghw`. The first resource we support is memory on Linux
systems.

Users can use the `ghw.WithCollectUsage(true)` function to instruct
`ghw` to gather usage information for the module in question.
Alternately, users can use the `GHW_COLLECT_USAGE=1` environs variable.
The following shows the effect of the variable:

```
jaypipes@lappie:~/src/github.com/jaypipes/ghw$ go run cmd/ghwc/main.go memory
memory (16GB physical, 16GB usable)
jaypipes@lappie:~/src/github.com/jaypipes/ghw$ GHW_COLLECT_USAGE=1 go run cmd/ghwc/main.go memory
memory (16GB physical, 16GB usable, 9GB used)
```

Issue #357

Signed-off-by: Jay Pipes <jaypipes@gmail.com>
Copy link
Collaborator

@ffromani ffromani left a comment

Choose a reason for hiding this comment

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

At glance, looks fine. The one and only reservation I have is that I'm not a fan of optional fields which are filled only if a global flag is set. I think we could have a couple or more of these fields in the various subsystems.
I'd consider an approach on which we add current resource usage in a more isolated way with respect the current return value. A very quick proposal could be to wrap the resource usage in substructs.
I'll have a proper review shortly in few days time tops.

@jaypipes
Copy link
Owner Author

At glance, looks fine. The one and only reservation I have is that I'm not a fan of optional fields which are filled only if a global flag is set. I think we could have a couple or more of these fields in the various subsystems. I'd consider an approach on which we add current resource usage in a more isolated way with respect the current return value. A very quick proposal could be to wrap the resource usage in substructs. I'll have a proper review shortly in few days time tops.

@ffromani Hi! :)

Yeah, I had a similar thought and actually originally I had an approach where I had a separate Usage struct for each module (to go along with the Info structs in the modules. But eventually I just thought it would be more straightforward to add the fields to the main Info structs themselves.

For things like memory usage, we will always need to determine the structure (NUMA topology) of the system itself and then add usage per NUMA node (on Linux via /sys/devices/system/node/nodeX/meminfo) so we are always going to need to grab the Info structs... so I thought it easier to just add usage fields to the Info structs themselves... that way, we don't need to do any alternate JSON/YAML serialization or all the plumbing for the Info.load() methods...

@jaypipes
Copy link
Owner Author

@ffromani we could also consider collecting usage information by default and making the collection of usage information disable-able via flag?

@jaypipes jaypipes marked this pull request as draft December 31, 2023 15:40
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.

2 participants