Re: [PATCH v2 4/4] MIPS: perf: Add support for 64-bit perf counters.

[David Daney <ddaney@caviumnetworks.com>]

On 01/26/2011 10:24 PM, Deng-Cheng Zhu wrote:
> Using your attached patch, I experimented -c and -F by 'ls /'. The numbers
> I used are 10, 1000 and 100000 for both -c and -F.
>
> The number of samples I got was 24 all the way. That means the event period
> to sample and the profiling frequency do not affect the results on MIPS32
> platform. While working on the old code, the system had the following
> results:
>
> -c 10: The system seems busy dealing with interrupts. And the following log
>         was printed out:
>         ================================================
>         hda: ide_dma_sff_timer_expiry: DMA status (0x24)
>         hda: DMA interrupt recovery
>         hda: lost interrupt
>         ================================================
>         This does need to be fixed later on.
> -c 1000: ~11085 samples
> -c 100000: ~48 samples ('perf report' still showed some data.)
> -F 10: ~118 samples
> -F 1000: ~352 samples
> -F 100000: ~379 samples
>
> I'll try to take time to look into the patch to see if anything can be
> changed.
>

I have found it useful to enable tracing, and then placing 
trace_printk() in mipspmu_event_set_period() to look at the values of:

sample_period, period_left that are being used.

Also you could use a trace_printk() in mipsxx_pmu_write_counter() to 
check the value being written to the register.

What hardware are you using to test this?  I wonder if there is a board 
with a 32-bit CPU that I could get access to.

David Daney


>
> Deng-Cheng
>
>
> 2011/1/26 David Daney<ddaney@caviumnetworks.com>:
>> On 01/24/2011 07:42 PM, Deng-Cheng Zhu wrote:
>>>
>>> Hi, David
>>>
>>>
>>> This version does fix the problem with 'perf stat'. However, when working
>>> with 'perf record', the following happened:
>>>
>>> -sh-4.0# perf record -f -e cycles -e instructions -e branches \
>>>>
>>>> -e branch-misses -e r12 find / -name "*sys*">/dev/null
>>>
>>> [ perf record: Woken up 1 times to write data ]
>>> [ perf record: Captured and wrote 0.001 MB perf.data (~53 samples) ]
>>
>>
>> I get the same thing.  What happens if you supply either '-c xxx' or '-f
>> xxx'?
>>
>> I get:octeon:~/linux/tools/perf# ./perf record -e cycles /bin/ls -l /
>> total 100
>> drwxr-xr-x   2 root root  4096 2010-11-12 11:39 bin
>> [...]
>> drwxr-xr-x  13 root root  4096 2007-05-25 12:28 var
>> [ perf record: Woken up 1 times to write data ]
>> [ perf record: Captured and wrote 0.002 MB perf.data (~82 samples) ]
>>
>> Almost no samples as you got.
>>
>> But if I do:
>>
>> octeon:~/linux/tools/perf# ./perf record -F 100000 -e cycles /bin/ls -l /
>> total 100
>> drwxr-xr-x   2 root root  4096 2010-11-12 11:39 bin
>> [...]
>> drwxr-xr-x  13 root root  4096 2007-05-25 12:28 var
>> [ perf record: Woken up 1 times to write data ]
>> [ perf record: Captured and wrote 0.404 MB perf.data (~17653 samples) ]
>>
>> Look many more samples!
>>
>> The question is, what is it supposed to do?
>>
>> If you can get a reasonable number of samples out if you supply -c or
>> -F, then I would argue that it is working and the default settings for
>> -F are not a good fit for your test case.
>>
>> I have slightly changed the patch.  You could try the attached version
>> instead and tell me the results.
>>
>>
>> David Daney
>>
>>
>>
>