This question is about the SUMMARY TAB
I have an application that uses a subset of the available CPUs on the server. Let's say I have 16 cores but I set OMP_NUM_THREADS to 8 and run an analysis.
IF i want the summary to filter and show summary for just my 8 cpus, and not the entire 16 available, how do I do this?
And yes, I know I can use Filters on the other tabs but there seems to be no way to tell the Summary tab to summarize data on a subset of cpus or threads, is there? If so, how?
What aspect, in particular, are you wanting to change?
It depends a little on the analysis type you selected. One thing I know you can do is affect the CPU Usage Histogram by moving the sliders at the bottom of the x-axis labels (see below).
Thanks David, that is helpful. However, it would be nice if a global filter could be set to filter on cpus or threads and have that apply to all tabs and all displays. For example, on Summary:Elapsed Time:cpi it would be nice to see the cpi for just those selected threads. Same for Summary:Hotspots.
The sliders on Summary:Histogram is ok. Still the x-axis didn't change and showed all 16 system cpus, only the little colored bars for idle, poor, ok ideal and over changed. I suppose that makes sense as a person might want to know what was available on the system and the subset you used. Sandia customer wanted the x-axis to update to JUST the subset of cpus used for the run.
I spoke to the customer on this some more. We think we have a reasonable Feature Request to propose. Here are our thoughts
In the Project Properties we're setting "CPU mask" before running the collection. Is that mask stored with the collected data? If so, could we ask that the Summary page honor and use the CPU Mask for all it's displays and all other tabs and displays?
Does this sound like a reasonable CQ Feature Request?
And changing the sliders, changes the display of utilization in the Bottom Up view. So, setting "Good" to be 8 processors would show whether functions were under or over utilizing 8 cores.
BTW, I don't think the number of cores is going to change the CPI, at least, not if you profiled "a" process. CPI is a result of clockticks / instructions retired. That means, all clockticks for a process divided by all instructions retired for that process. Should be representative of the process' CPI, regardless of the number of "available" cores.