Re: [Qemu-devel] User space vs kernel space instructions distribution.

[Shlomo Pongratz]

See inline

On Wednesday, July 22, 2015, Christopher Covington <address@hidden> wrote:
> On 07/14/2015 04:45 AM, Peter Maydell wrote:
> > On 14 July 2015 at 09:32, Shlomo Pongratz <address@hidden> 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