From: Christopher Covington <cov@codeaurora.org>
To: Peter Maydell <peter.maydell@linaro.org>,
Shlomo Pongratz <shlomopongratz@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] User space vs kernel space instructions distribution.
Date: Wed, 22 Jul 2015 12:45:53 -0400 [thread overview]
Message-ID: <55AFC8C1.5020908@codeaurora.org> (raw)
In-Reply-To: <CAFEAcA8DBYGLhPizY9KzojGAeDhKg7umgnUvQ_zDrXpCa8zWWA@mail.gmail.com>
On 07/14/2015 04:45 AM, Peter Maydell wrote:
> On 14 July 2015 at 09:32, Shlomo Pongratz <shlomopongratz@gmail.com> 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'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.
Chris
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2015-07-22 16:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-14 8:32 [Qemu-devel] User space vs kernel space instructions distribution Shlomo Pongratz
2015-07-14 8:45 ` Peter Maydell
2015-07-22 16:45 ` Christopher Covington [this message]
2015-07-22 16:54 ` Peter Maydell
2015-07-23 7:57 ` Shlomo Pongratz
2015-07-23 8:32 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55AFC8C1.5020908@codeaurora.org \
--to=cov@codeaurora.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=shlomopongratz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.