mpstat's view is at the operating system level. The OS has assigned a thread to run on the core. The OS doesn't care whether that thread spends its time quanta trying to issue an instruction every cycle, or stalled waiting for memory. Either way the OS cannot assign another software thread to that virtual processor.
At the hardware level corestat gives you an indication of whether the core is utilised. Which is what I think you're after. A core can be busy executing instructions or it can be stalled waiting on memory. Either way the OS views the core as having been assigned work to do. However, there's no simple counter which tells you what the thread would run in isolation. You might find it interesting to read this article on using the performance counters to determine the time the thread is spending not executing instructions: http://developers.sun.com/solaris/articles/t1t2_perf_counter.html You might also want to take a look at ripc, which is part of spot, which breaks down a single threads activity into the various stall states. http://cooltools.sunsource.net/spot [Also in the July Sun Studio Express release.] Regards, Darryl. On 10/ 3/08 08:21 AM, Elad Lahav wrote: > Thanks, Steve, but the blog does not answer my question. > With vmstat reporting 50% idle time, and the core greatly under-utilised > (about 25%), how > do you determine that a *single thread* has reached its limit? I would expect > 0% idle time > on vmstat in that case. > The main issue is that the number of instructions-per-second that a thread > can execute > depends on its own CPI, but also on the execution pattern of the other > threads in the > core. So a thread that can do 700 instructions/sec, if running alone on the > core, will do > much less when sharing the core with other threads. Thus, you're left with > mpstat to tell > you whether the thread is saturated. Only I'm not sure whether mpstat is > doing the right > thing. > > --Elad > > Steve Sistare wrote: >> See Ravi Talashikar's blog for an explanation of CPU vs core >> utilization on CMT architectures such as the T1000: >> http://blogs.sun.com/travi/entry/ultrasparc_t1_utilization_explained >> >> - Steve > > _______________________________________________ > perf-discuss mailing list > perf-discuss@opensolaris.org -- Darryl Gove Compiler Performance Engineering Blog: http://blogs.sun.com/d/ Book: http://www.sun.com/books/catalog/solaris_app_programming.xml _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
