See inline On Wednesday, July 22, 2015, Christopher Covington <c...@codeaurora.org> wrote:
> On 07/14/2015 04:45 AM, Peter Maydell wrote: > > On 14 July 2015 at 09:32, Shlomo Pongratz <shlomopongr...@gmail.com > <javascript:;>> wrote: > >> Hi, > >> > >> I'm running aarm64 QEMU and I'm counting the number of instructions > which > >> "belong" to user space vs kernel space. My measurements shows that 99 > >> percent of instructions are in kernel space. > > How are you counting? Instrumenting QEMU? I have an array of the three address spaces user/unmapped/kernel and array of 4 els and I'm add the TB's icount to the appropriate entry according to the env->pc and arm_current_el(env) before the block execution. As I wrote before I disabled chaining so TB's icount is the number of executed instructions. > >> I've used both the address of the instructions and the EL just to be > sure. I > >> also added an option to disable block chaining just to make sure that > all > >> the instructions in every TB is counted. > >> When examining some kernel's instructions against the objdump of the > kernel > >> I've noticed that most of them are in interrupts/timers area. > >> > >> Does this make sense? > >> Did someone also encountered this phenomenon? > > > > Depends entirely on your workload, obviously. If the system only > > boots then most instructions will be in kernel space. If the system > > is only sitting idle then it'll just be executing the kernel space > > idle loop. If you're measuring solely the section of time where > > a userspace program is doing real work with the CPU and you're > > still seeing a 99% figure then the obvious conclusion would be that > > your measurement approach is wrong... > > > > If your measurement instrumentation is intrusive and is significantly > > slowing down QEMU then you'll naturally find that the guest spends > > more time in timer interrupt handling, because the timer interrupts > > come in in real time, and you've just effectively reduced the speed > > of your CPU, so it can get less useful work done between timer > > interrupts. > > I find such behavior undesirable. As best I understand, -icount exists to > provide an alternative, although it may have bugs. I've tinkered with > -icount > a little, but I have yet to come up with useful tests to verify its correct > behavior. If anyone has suggestions for how to test it, I'd be eager to > hear. > I don't use -icount. > > Chris > > -- > Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project >
