Change:
return &bo, nil } <ins> // sleepOp defines an op that can be used to sleep for a specified amount of time. // This is useful in simulating workloads that require some sort of time-based synchronisation. type sleepOp struct { // Must be "sleep". Opcode string // duration of sleep. Duration time.Duration } func (so *sleepOp) UnmarshalJSON(data []byte) (err error) { var tmp struct { Opcode   string Duration string } if err = json.Unmarshal(data, &tmp); err != nil { return err } so.Opcode = tmp.Opcode so.Duration, err = time.ParseDuration(tmp.Duration) return err } func (so *sleepOp) isValid(_ bool) error { if so.Opcode != sleepOpcode { return fmt.Errorf("invalid opcode %q; expected %q", so.Opcode, sleepOpcode) } return nil } func (so *sleepOp) collectsMetrics() bool { return false } func (so sleepOp) patchParams(_ *workload) (realOp, error) { return &so, nil } </ins> func BenchmarkPerfScheduling(b *testing.B) { testCases, err := getTestCases(configFile) if err != nil {

Discussion:
Note: this issue should be viewed in the context of . What would you like to be : Currently we support three types of ops: , , . This issue proposes adding a op that would simulate user action by causing the main thread to sleep. Note: I don't have a use-case for this in mind, but one can come up with trivial and contrived examples easily. Why is this needed: Not clear at this time. This is just an open discussion where others can chime in with whether this will be useful. /sig scheduling /sig testing (Not assigning myself until we can figure out if/how we want this.)
when you get a chance, can you group all enhancements issues relate to the new benchmark framework under one issue with a task list.
/assign
see
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
/unassign
I'd like to take this one /assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Instructions 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
There is still an active pull request for this issue. /remove-lifecycle rotten /reopen
Reopened this issue. <detailsIn response to : There is still an active pull request for this issue. /reopen </details
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