Date: Mon, 26 Nov 2012 04:12:03 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: "freebsd-emulation@freebsd.org" <freebsd-emulation@FreeBSD.org> Subject: Re: VirtualBox 4.2.4 on FreeBSD 9.1-PRERELEASE problem: VMs behave very different when pinned to different cores Message-ID: <50B2CFF3.9060407@FreeBSD.org> In-Reply-To: <50B29D53.5080802@FreeBSD.org> References: <CA%2Bkq2xvh3j5CM7UzRVfXCeLhHwpTY%2B_M7dCJx0c27NtV8EVJwg@mail.gmail.com> <CAE-m3X1UPsy%2Bwbqm_02JpXMr-UO3m7N6z_ZwY2HNo4GL0YUi1w@mail.gmail.com> <CA%2Bkq2xva61m_bHdzBZM2TYL5z7XiohvkxsYWtOyoBwQkpyvp0A@mail.gmail.com> <50AFAD05.1050604@FreeBSD.org> <CA%2Bkq2xv%2BU4ZnfK=1js4PRaNpTNdW-y-G50GV4%2BMVP0LugBf1pQ@mail.gmail.com> <50B25C17.20208@FreeBSD.org> <50B29D53.5080802@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26.11.2012 00:36, Andriy Gapon wrote: > 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! I've tried to calculate those offsets manually to make schedgraph happy. It seems that while running on one CPU VirtualBox consumes all the CPU time but behaves different on another CPU. I am not sure how it is related to scheduler or specific CPUs. My only guess that there is some unexpected synchronization happens that makes VirtualBox to do some extra spinning. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50B2CFF3.9060407>