From owner-freebsd-emulation@FreeBSD.ORG Wed Nov 28 15:42:55 2012 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BBB86ECD; Wed, 28 Nov 2012 15:42:55 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6357E8FC16; Wed, 28 Nov 2012 15:42:54 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA27993; Wed, 28 Nov 2012 17:42:51 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50B630FB.4050403@FreeBSD.org> Date: Wed, 28 Nov 2012 17:42:51 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alex Chistyakov Subject: Re: VirtualBox 4.2.4 on FreeBSD 9.1-PRERELEASE problem: VMs behave very different when pinned to different cores References: <50AFAD05.1050604@FreeBSD.org> <50B25C17.20208@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-emulation@freebsd.org" , Alexander Motin X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 15:42:55 -0000 on 27/11/2012 02:45 Alex Chistyakov said the following: > On Mon, Nov 26, 2012 at 11:10 AM, Alex Chistyakov wrote: >> A DTrace result for "bad" core is at https://gist.github.com/4145782 >> and a result for "good" core is at https://gist.github.com/4146946 > > Okay, I have finally found a way to utilize PMP and got some > stacktraces for "good" and "bad" VM runs. > The "good" results are here: https://gist.github.com/4151328 and the > "bad" ones are here: https://gist.github.com/4151343 > I was sampling for 160 seconds both times, a sample per a second. I > used a script titled "Full technology demonstration" on > http://poormansprofiler.org/ so numbers on the left are total counts > of repeating stacktraces. > As you can see the second result has "select,select,listenerRun,??,??" > and "select,select,clientInput,??,??" samples so I guessed they can be > related to VNC/VRDE. I disabled VRDE and was able to boot the VM on > the "bad" core without major problems then. > But CPU usage remained quite high on the "bad" core and ping was very > unstable too so this was not the end of the story. > I collected PMP stats for the "bad" core with VRDE disabled: > https://gist.github.com/4151530 > A lot of time seems to be spent in VMMR3HwAccRunGC call. Well, this > function is just a bridge for the guest code, so I'm not sure how to > interpret this fact. I am inclined to interpret both this data and the DTrace data as some sort of churn in the guest or in userland part of VirtualBox. Is the problem easily reproducible with different kinds of guests? Do you have any unusual configuration settings for the VM (especially timer related)? What kind of guest do you run? I feel tempted to draw some connection between this problem and the TSC skew, but I am not sure what it could be. >From the Dtrace profiling, here is where all the extra time gets spent: 12777 100783 VBoxHeadless 0xffffffff81f6477c 0xffffffff81f70bd4 vboxdrv.ko`supdrvIOCtlFast+0x8b vboxdrv.ko`VBoxDrvFreeBSDIOCtl+0xa5 kernel`devfs_ioctl_f+0x7a kernel`kern_ioctl+0x106 kernel`sys_ioctl+0xfd kernel`amd64_syscall+0x334 kernel`0xffffffff80745e07 10317 As far as I understand supdrvIOCtlFast is used to pass guest code for execution. Could you please also run the following script (in the bad case)? fbt::supdrvIOCtlFast:entry { @counts[curthread->td_oncpu, args[1], args[0], args[2], args[3]] = count(); } END { trunc(@counts, 40); printa(@counts); } -- Andriy Gapon