From owner-freebsd-emulation@FreeBSD.ORG Sun Nov 25 22:36:14 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 7AF5FCAA; Sun, 25 Nov 2012 22:36:14 +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 3CE448FC0C; Sun, 25 Nov 2012 22:36:13 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA22708; Mon, 26 Nov 2012 00:36:04 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tcko0-000LHE-Gv; Mon, 26 Nov 2012 00:36:04 +0200 Message-ID: <50B29D53.5080802@FreeBSD.org> Date: Mon, 26 Nov 2012 00:36:03 +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: <50B25C17.20208@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 25 Nov 2012 22:36:14 -0000 on 25/11/2012 19:57 Andriy Gapon said the following: > on 24/11/2012 00:17 Alex Chistyakov said the following: >> I collected two samples and put them here: http://1888.spb.ru/samples.zip >> sched-cpu0.ktr is for a VM running on CPU #0 and sched-cpu1.ktr is for >> a VM running on CPU #1 >> They seem to be very different. > > It looks like you didn't stop ktr tracing before running ktrdump or something > like that. schedgraph can not grok the files because it believes that the > timestamps are incorrect. > > # - While the workload is continuing (i.e. before it finishes), disable > # KTR tracing by setting 'sysctl debug.ktr.mask=0'. This is necessary > # to avoid a race condition while running ktrdump, i.e. the KTR ring buffer > # will cycle a bit while ktrdump runs, and this confuses schedgraph because > # the timestamps appear to go backwards at some point. Hmm, looks like this assessment is not correct. I now think that the root cause of schedgraph issue might be a too wild difference in what TSC counters produce on different (logical/physical) CPUs. E.g.: 131059 1 33232414877586 ... 131058 1 33232414876546 ... 131057 3 33232416064514 ... 131056 3 33232416064198 ... Or even: 131038 0 33232862369416 ... 131037 3 33232409671570 ... 131036 0 33232862367256 ... 131035 3 33232409670982 ... That's 455111586 ticks! > Could you please also provide the CPU identification block from dmesg? This is even more interesting now. -- -- Andriy Gapon