> -----Original Message----- > From: Sundaram, Senthilkumar > Sent: Thursday, November 08, 2012 6:40 PM > To: Marc Zyngier > Cc: kvmarm@xxxxxxxxxxxxxxxxxxxxx; Sundaram, Senthilkumar > Subject: RE: Using perf: Getting guest kallsyms > > > > > > > -----Original Message----- > > From: Marc Zyngier [mailto:marc.zyngier@xxxxxxx] > > Sent: Thursday, November 08, 2012 5:12 PM > > To: Sundaram, Senthilkumar > > Cc: kvmarm@xxxxxxxxxxxxxxxxxxxxx > > Subject: Re: Using perf: Getting guest kallsyms > > > > On 08/11/12 10:34, Sundaram, Senthilkumar wrote: > > > Hi > > > > > > I am running within A15 fast model. > > > > > > I want to run perf ( from the Host) and record guest cpu utilization > > > across > > various modules & functions. For this it looks like I need guest > > kallsyms. How do I get this? > > > > I wonder how useful this will be. We don't have any code that performs > > a backtrace in the guest yet, so all you will know is the PC at the > > moment the the perf interrupt fired. You're welcome to contribute > > patches implementing this though (hint, hint...). > > > > Otherwise, you can probably use the System.map file generated when you > > compiled your guest kernel. > > > [[ss]] Mark, > > Perf command is explicitly asking for guestkallsyms as one of the options, so I > was looking for it. > > Are you suggesting that I use system.map as the value of the guestkallsyms > argument in the perf command > > I thought if the symbols were relocated during the loading of the kernel > system.map may not be accurate? But I will give it a shot. > [[ss]] I didn't check thoroughly, but a quick scan showed that the system.map & /proc/kallsyms had same addresses. So system.map must be fine. Also, the guest has the same kernel as the host , so I could use the host kallsyms. But I have another problem. I am not able to get detailed breakdown like what Chris was reporting in an earlier thread. Here is his comment : > I ran perf a bit yesterday and it seems we spend approx. 5% of the vcpu > thread's time on vgic save/restore. I don't know if this can be optimized at all > though. > I am not sure how to get that level of detail.. I only get a very high level breakdown. Perf record -p <qemu-pid> Perf report Here is what I got, I don't know how to drill down further to get more detailed breakdown [[31m 16.67%[[m qemu-system-arm qemu-system-arm-perf [.] __udivsi3 [[31m 16.67%[[m qemu-system-arm [kernel.kallsyms] [k] vfs_read [[31m 16.67%[[m qemu-system-arm [kernel.kallsyms] [k] do_select [[31m 8.33%[[m qemu-system-arm qemu-system-arm-perf [.] qemu_chr_fe_write [[31m 8.33%[[m qemu-system-arm qemu-system-arm-perf [.] qemu_timer_expired [[31m 8.33%[[m qemu-system-arm qemu-system-arm-perf [.] pthread_mutex_lock [[31m 8.33%[[m qemu-system-arm qemu-system-arm-perf [.] __pthread_mutex_unlock_usercnt [[31m 8.33%[[m qemu-system-arm [kernel.kallsyms] [k] tty_write [[31m 8.33%[[m qemu-system-arm [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore > Thanks > Senthil > > M. > > -- > > Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
