move thread switch tracing from mi_switch to sched_switch

[avg]

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.

[avg]

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 ?

[markj]

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.

[jhb]

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.

Agreed. They were added solely for use with schedgraph.