Open jaypipes opened 7 months ago
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...
@ffromani we could also consider collecting usage information by default and making the collection of usage information disable-able via flag?
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 instructghw
to gather usage information for the module in question. Alternately, users can use theGHW_COLLECT_USAGE=1
environs variable. The following shows the effect of the variable:Issue #357