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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxx>:
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








[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux