Hi Qihua Wu,
Qihua Wu wrote:
Now cpu7 has most of the interrupt (delete other cpu stats as they are 0).
so why the execname is sched when interrupt happens?
Most interrupts run in a kernel thread set aside for
handling interrupts. There are 10 threads per cpu
for interrupt levels 1 through 10. All of these threads
will show up as being part of the "sched" process.
(In fact, on an idle system, you'll probably have over
300 threads, and about 200 of them will say they belong to "sched".
These are various taskq(9f) threads, garbage collectors, interrupt
threads, and others.). I think what you probably want to know
is who was interrupted.
max
device | cpu0 %tim cpu1 %tim cpu2 %tim cpu3
%tim cpu4 %tim cpu5 %tim cpu6 %tim cpu7 %tim
------------+--------------------------------------------------------------------------------------------------------------------------
ehci#0 | 0 0.0 0 0.0 0 0.0 0
0.0 0 0.0 2 0.0 0 0.0 0 0.0
nge#0 | 0 0.0 0 0.0 0 0.0 0
0.0 0 0.0 0 0.0 0 0.0 6260 2.9
nge#1 | 0 0.0 0 0.0 0 0.0 0
0.0 0 0.0 0 0.0 0 0.0 2 0.0
nv_sata#0 | 0 0.0 0 0.0 0 0.0 0
0.0 0 0.0 2 0.0 0 0.0 0 0.0
nv_sata#2 | 0 0.0 0 0.0 0 0.0 0
0.0 0 0.0 0 0.0 0 0.0 6260 0.5
On Thu, Jan 21, 2010 at 6:54 PM, Michael Schuster
<michael.schus...@sun.com>wrote:
Qihua Wu wrote:
Why sched is often interrupt on cpu 0 instead of distribution evenly on
all cpu?
dtrace -n 'sdt:::interrupt-start { @num[execname,cpu] = count(); }'
dtrace: description 'sdt:::interrupt-start ' matched 1 probe
the output of intrstat may help.
Michael
--
Michael Schuster http://blogs.sun.com/recursion
Recursion, n.: see 'Recursion'
------------------------------------------------------------------------
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
