On Fri, Feb 12, 2016 at 08:12:26PM +0000, Mahmood Naderan wrote: > >So it's easy to imagine that ~100 threads or more > > could give you these results.So, you mean that the result I got is the > > aggregation number of all threads? I agree with that. > >so the thread is asleep and other threads > >can be making forward progress; lwp_cond_wait(), lwp_park(), and pollsys() > >in particular.? So even on a low-CPU count machine, you could have hundreds > >of threads sleeping.?Sorry I didn't understand. How did you conclude that? > > > >If you change the script to replace 'timestamp' with 'vtimestamp', that will > >only record the on-CPU time, which will be much lower, since all time > >sleeping > >won't be counted > By "on-CPU", do you mean the active thread?
Hi Mahmood, timestamp is wall-clock time, in nanoseconds; so if one second has passed since the last time it was read, it will increase by 10^9 = 1,000,000,000. The value of timestamp read from different threads can be compared. vtimestamp is on-cpu time (e.g. active) time; so if the thread has continually run for the past second, it will also increase by 10^9. But if the thread went to sleep for a second and just woke back up, it will only have increased by a small amount. The values of vtimestamp read from different threads cannot be reasonably compared. Cheers, - jonathan ------------------------------------------- dtrace-discuss Archives: https://www.listbox.com/member/archive/184261/=now RSS Feed: https://www.listbox.com/member/archive/rss/184261/25769126-e243886f Modify Your Subscription: https://www.listbox.com/member/?member_id=25769126&id_secret=25769126-8d47a7b2 Powered by Listbox: http://www.listbox.com
