Alexander Kolbasov wrote: > >Aubrey, > >> Hi Jonathan, >> >> Nice to see you have interest. >> >> We are discussing the metrics of NUMAtop, and so far the proposal is >> that the following parameters will be reported by NUMAtop as the >metrics. >> >> 1) sysload - cpu sensitive >> 2) LLC Miss per Instruction - memory sensitive >> 3) LLC Latency ratio - memory locality >> 4) the percent of the number of LMA/RMA access / total memory access >> - 4.1) LMA/(total memory access)% >> - 4.2) RMA/(total memory access)% > >Is it some sort of an aggregation tool over cputrack(1) that works over >all >processes or threads of a process and presents some aggregated view of >memory-related hardware counters? Or, to put it differently, is it >cputrack(1) >aggregation tool or something that collects NUMA-related information >from >different sources and displays it in a combined view? > >- akolb
Currently NUMAtop is in the design phase. We had a prototype but it's not perfect. After got a few valuable feedbacks from Eric and John, We are trying to improve it. NUMAtop will focus on NUMA-related characteristic. Yes, the information is collected from memory-related hardware counters. Some of these counters are already supported in kcpc and libcpc, while some of them are not. We probably need to use Precise Event Based Sampling(PEBS), which seems not in the current solaris kernel and libcpc implementation. A good combined view is a part of our goal. It will show how effective the application is using the local memory. And we expect NUMAtop is able to help the user to figure out where is not effective and why. What's more, if NUMAtop can make a better memory placement strategy suggestion to the user, it would be great. We are trying to make NUMAtop to be a useful tool to diagnose NUMA-related memory placement problems and help to find solutions. We certainly need help from you experts, :) Thanks, -Aubrey _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
