Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 0 additions & 20 deletions cmd/scheduler/metrics.go
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,6 @@ import (
"fmt"
"log"
"net/http"
"strings"
"time"

"github.com/prometheus/client_golang/prometheus"
Expand Down Expand Up @@ -355,25 +354,6 @@ func (cc ClusterManagerCollector) Collect(ch chan<- prometheus.Metric) {
float64(ctrdevval.Usedcores),
val.Namespace, val.NodeID, val.Name, fmt.Sprint(ctridx), ctrdevval.UUID)
}
var totaldev int32
found := false
for _, ni := range *nu {
for _, nodedev := range ni.Devices.DeviceLists {
if strings.Compare(nodedev.Device.ID, ctrdevval.UUID) == 0 {
totaldev = nodedev.Device.Totalmem
found = true
break
}
}
if found {
break
}
}
klog.V(4).InfoS("Total memory for device",
"deviceUUID", ctrdevval.UUID,
"totalMemory", totaldev,

@Eshiv-Pandey Eshiv-Pandey Jul 28, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Great find! This looks reasonable tbh. The removed scan only feeds a verbose log line and does not affect any emitted metric. One question tho... was this totalMemory log used for any debugging flow, or is the node memory limit metric enough for that case?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Thanks! I checked the full metrics collector flow. totaldev was only used by that klog.V(4) message; it does not affect emitted metrics, scheduling, or allocation.
For debugging device capacity, the collector already exposes the same per-device total-memory information through hami_gpu_memory_limit_bytes and hami_node_gpu_overview (device_memory_limit). So the verbose log is redundant, and removing the scan does not reduce Prometheus visibility.
If maintainers prefer retaining a V(4) log for troubleshooting, I can add one using the already available per-device data, without restoring the all-node scan.

"nodeID", val.NodeID,
)
}
}
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

the loop u deleted broke on the first uuid hit while ranging *nu, which is a map, and the pods node was already sitting in val.NodeID, so what did that V(4) line print if the same uuid ever turned up under 2 nodes?

Expand Down
Loading