move thread switch tracing from mi_switch to sched_switch
ClosedPublic
Actions

Authored by avg on Mar 11 2017, 4:09 PM.

Details

Reviewers

markj
jhb
julian

Commits

rS315851: move thread switch tracing from mi_switch to sched_switch

Summary

This is done so that the thread state changes during the switch
are not confused with the thread state changes reported when the thread
spins on a lock.

Here is an example, three consecutive entries for the same thread (from top to
bottom):

KTRGRAPH group:"thread", id:"zio_write_intr_3 tid 100260", state:"sleep", attributes: prio:84, wmesg:"-", lockname:"(null)"
KTRGRAPH group:"thread", id:"zio_write_intr_3 tid 100260", state:"spinning", attributes: lockname:"sched lock 1"
KTRGRAPH group:"thread", id:"zio_write_intr_3 tid 100260", state:"running", attributes: none

The above trace could leave an impression that the final state of
the thread was "running".
After this change the sleep state will be reported after the "spinning"
and "running" states reported for the sched lock.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

avg created this revision.Mar 11 2017, 4:09 PM

Herald added a subscriber: imp. · View Herald TranscriptMar 11 2017, 4:09 PM

Harbormaster completed remote builds in B7991: Diff 26148.Mar 11 2017, 5:14 PM

jhb accepted this revision.Mar 11 2017, 8:01 PM

This revision is now accepted and ready to land.Mar 11 2017, 8:01 PM

markj accepted this revision.Mar 12 2017, 1:08 AM

Another thought that has just occurred to me.
Do the running/spinning traces in the lock code really belong KTR_SCHED?
I think that spinning is the same as running from the scheduler's perspective, so I am not sure if those state switches are significant for the scheduler analysis.
Maybe they should be moved to KTR_LOCK ?

In D9961#206228, @avg wrote:

Another thought that has just occurred to me.
Do the running/spinning traces in the lock code really belong KTR_SCHED?
I think that spinning is the same as running from the scheduler's perspective, so I am not sure if those state switches are significant for the scheduler analysis.
Maybe they should be moved to KTR_LOCK ?

I find it useful when looking at traces with schedgraph. Spinning threads are technically running, but they are not making progress and they consume a scheduler-managed resource as they spin. So it's worth making the distinction IMO - I'd vote for keeping it.

In D9961#206378, @markj wrote:

In D9961#206228, @avg wrote:

Another thought that has just occurred to me.
Do the running/spinning traces in the lock code really belong KTR_SCHED?
I think that spinning is the same as running from the scheduler's perspective, so I am not sure if those state switches are significant for the scheduler analysis.
Maybe they should be moved to KTR_LOCK ?

I find it useful when looking at traces with schedgraph. Spinning threads are technically running, but they are not making progress and they consume a scheduler-managed resource as they spin. So it's worth making the distinction IMO - I'd vote for keeping it.