kernel - Fix sys% time reporting
commitc6a766f42233dbe511d3ecfb945a20440c968533
authorMatthew Dillon <dillon@apollo.backplane.com>
Wed, 13 Sep 2017 02:50:47 +0000 (12 19:50 -0700)
committerMatthew Dillon <dillon@apollo.backplane.com>
Wed, 13 Sep 2017 03:06:51 +0000 (12 20:06 -0700)
tree256cd8fdf0b025e1206e7a31ec4b6e691db2164b
parent794d80aa519b394b3174f20776a6a667452422db
kernel - Fix sys% time reporting

* Fix system time reporting in systat -vm 1, systat -pv 1, and process
  stats.

* Basically the issue is that when coincident systimer interrupts occur,
  such as when the statclock, hardclock, and schedclock all fire at the
  same time, the statclock must execute first in order to properly detect
  the state the current thread is in.  If it does not, it may see a lwkt
  thread schedule by one of the other systimers and improper dock the
  current thread as being in 'system' time.

* The various systimer interrupts could wind up out of phase and
  desynchronized due to the tsc_frequency not being perfectly divisible
  by the requested frequencies.  In addition, various timers could queue
  in an undesirable order due to being different integral frequencies of
  each other.

* Refactor the systimer API a bit, adding new functions which guarantee
  synchronization for nominally requested frequencies and which guarantee
  ordering for coincident systimer events (which statclock uses).  This
  should completely solve the problem.

* Also, if the RQF_INTPEND flag is set, count as interrupt time.  This
  will give us a slightly more accurate understanding of interrupt overhead
  (alternatively we could do this test for just the case where curthread is
  the idlethread, which might be more accurate).
sys/kern/kern_clock.c
sys/kern/kern_systimer.c
sys/kern/lwkt_thread.c
sys/sys/systimer.h