Code change:
} } <del> func TestHistogramClear(t *testing.T) { samples := []float64{0.5, 0.5, 0.5, 0.5, 1.5, 1.5, 1.5, 1.5, 3, 3, 3, 3, 6, 6, 6, 6} bounds := []float64{1, 2, 4, 8} h := samples2Histogram(samples, bounds) if *h.SampleCount == 0 { t.Errorf("Expected histogram .SampleCount to be non-zero") } if *h.SampleSum == 0 { t.Errorf("Expected histogram .SampleSum to be non-zero") } for _, b := range h.Bucket { if b.CumulativeCount != nil { if *b.CumulativeCount == 0 { t.Errorf("Expected histogram bucket to have non-zero comulative count") } } } h.Clear() if *h.SampleCount != 0 { t.Errorf("Expected histogram .SampleCount to be zero, have %v instead", *h.SampleCount) } if *h.SampleSum != 0 { t.Errorf("Expected histogram .SampleSum to be zero, have %v instead", *h.SampleSum) } for _, b := range h.Bucket { if b.CumulativeCount != nil { if *b.CumulativeCount != 0 { t.Errorf("Expected histogram bucket to have zero comulative count, have %v instead", *b.CumulativeCount) } } if b.UpperBound != nil { *b.UpperBound = 0 } } } </del> func TestHistogramValidate(t *testing.T) { tests := []struct { name string

Related discussion:
text: In the new scheduler performance testing framework, (bool) is provided to benchmark performance of pods created in an "operator": (L11 below) However, the initialized Pods created in L5~L7 seem to be also benchmarked, although it doesn't specify . (please see the reproduce steps below). I think it's b/c once scheduler starts, the associated Prometheus artifacts are also up, and it's a single in-memory datastore. So no matter we start to collect the metric in which step, the prometheus data is already up-to-date. In the above workload config, the final data have benchmarked 1500 pods instead of 1000 pods. I guess it won't work either if running in the pod initialization step or not. Unless we manage a breakpoint at the end of each step, and calculate delta histogram for the step that specifies . Pods created in step without are not benchmarked. Apply the following diff: And then run: You will get an output sth. like: /sig scheduling
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Could you please help confirm if it's an issue?
cc
Unfortunately, does not apply for metrics gathered from . As you mentioned. The default gatherer collects all metrics produced by the scheduler. It's the scheduler itself who knows pod specs and would have to decide which pods will get ignored when updating metrics. The question is if computing metrics for a subset of pods processed by the scheduler is a valid use case.
This is probably what we want. Is something like that possible ?
I think being able to absolutely ignore certain pods for metrics is an overkill.
The use case is to ignore the pods created in steps that don't specify , so as to collect the Pod metrics create at particular step(s) (). Otherwise, the semantics of option is quite misleading. Nope, that's not the intention. We don't need to target certain pods, like using label selector or whatever. Just as I mentioned, measure pods created at particular steps.