The script does work and most of output are the information I need, but only
without the output of "clk". Do I lost something special in above script?
Or do I need to manually assign "cpu_clk_unhalted.thread" to a special pic?
Worked for me. Manually assigning the event to a pic is not necessar
> Hi Jin Yao
>
> 1. Regarding your RMA example, wouldn't you be able
> to use the dtrace
> cpc provider to get this information?
>
> 2. How do you propose handling the case where both
> the proposed
> per-hardware thread data and overflow profiling are
> enabled?
>
> Thanks
> /kuriakose
>
Hi Jin Yao
1. Regarding your RMA example, wouldn't you be able to use the dtrace
cpc provider to get this information?
2. How do you propose handling the case where both the proposed
per-hardware thread data and overflow profiling are enabled?
Thanks
/kuriakose
_
> Hi All,
>
> When I use cputrack to track one process on a numa
> system
> (like nhm-ex) and want to see some performance events
> like
> “RMA” (Remote Memory Access) which the process
> costs.
>
> The cputrack can tell me the RMA value which the
> process costs
> on the whole system, eg: in
Let me introduce the patch's scenario.
1. Suppose we need to capture thread1 (use cpc_bind_pctx to bind to thread1).
2. Kernel allocates a slot array which is big enough to store the required
cpc events for thread1 on all cpus. Each slot will store the sampling
values
for the events on
Jin Yao wrote:
>Hi All,
>
>When I use cputrack to track one process on a numa system
>(like nhm-ex) and want to see some performance events like
>“RMA” (Remote Memory Access) which the process costs.
>
>The cputrack can tell me the RMA value which the process costs
>on the whole system, eg: in last
