From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46650) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHx9e-0002NW-3t for qemu-devel@nongnu.org; Wed, 22 Jul 2015 12:46:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZHx9Z-0005Zy-Ug for qemu-devel@nongnu.org; Wed, 22 Jul 2015 12:46:02 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:48218) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHx9Z-0005ZK-BH for qemu-devel@nongnu.org; Wed, 22 Jul 2015 12:45:57 -0400 Message-ID: <55AFC8C1.5020908@codeaurora.org> Date: Wed, 22 Jul 2015 12:45:53 -0400 From: Christopher Covington MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] User space vs kernel space instructions distribution. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Shlomo Pongratz Cc: qemu-devel On 07/14/2015 04:45 AM, Peter Maydell wrote: > On 14 July 2015 at 09:32, Shlomo Pongratz 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