On Thu, Apr 10, 2008 at 12:08:59PM -0400, Jonathan Adams wrote: > > Hrm; try dropping the ', ustack()' from the script; that way, you're > only considering kernel stacks, which should raise the amount of signal. > OK, this is again for 16k threads:
- 835 hits in unix`cpu_halt - 63 in unix`_resume_from_idle+0x83/genunix`restorectx+0x1f - 33 in unix`sys_syscall+0x100 = The following were entered from unix`sys_syscall+0x17b (cv_wait / cv_signal): - 53 in mutex_enter - 42 in genunix`sleepq_wakeone_chan+0x17 - 38 in genunix`thread_lock+0x19 - 36 in genunix`sleepq_insert+0x29 - 34 in genunix`sleepq_insert+0x4e - 32 in genunix`lwp_hash_lookup+0x27 The total number of hits (I assume that's the final number at the bottom of the dump) is 3948. The total running time was ~35 sec, and the cpu_halt is again ~20% of the time. A strange thing: the machine has two cores, but the dtrace output has the following header: CPU ID FUNCTION:NAME 1 2 :END What about the other CPU? Or is data from all CPUs aggregated into this output? > > >plockstat: processing aborted: Abort due to drop > > You probably need to increase the buffer sizes for this; add - > xaggsize=4m to start; if that doesn't help, add -xbufsize=1m, and if > that's still not working, make -xaggsize=16m. > plockstat -xaggsize=16m -xbufsize=16m still dies with the same message. I didn't increase the numbers further; I'm not sure where the memory is allocated from and I don't want to kill the machine (yet, at least not from the remote shell.. :-) BTW, I admire the system's stability -- it has successfully endured all of my weird torture-tests for 27 days without reboot :-)). Best regards, Zeljko. _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
