Date: Thu, 14 Apr 2011 10:44:48 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Dimitry Andric <dim@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r220584 - in head/sys: amd64/amd64 i386/i386 Message-ID: <201104141044.55789.jkim@FreeBSD.org> In-Reply-To: <4DA6D145.8070804@FreeBSD.org> References: <201104122349.p3CNn7kK039179@svn.freebsd.org> <201104131827.39373.jkim@FreeBSD.org> <4DA6D145.8070804@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 14 April 2011 06:49 am, Dimitry Andric wrote: > On 2011-04-14 00:27, Jung-uk Kim wrote: > ... > > >> will still read 0 from MSR_MPERF, leading to a division by zero. > >> Maybe just fallback to the second method in the 'else' branch > >> then? > > > > That means your VM has broken CPUID support. To get there, it > > has to meet two conditions, i.e., TSC is invariant and it has > > APERF/MPERF MSRs. > > Well, VM hosts like VMware and VirtualBox usually just return the > 'native' CPUID values to guests, but can't really support stuff > like those MSRs, for all kinds of reasons. > > I was just looking at this from a viewpoint of "it worked for > years, and now it broke". :) > > In any case, I don't see why a bit of defensive programming would > be bad here, so I propose the following patch to revert to the > 'old' way of estimating the rate, in case reading the MPERF MSR > returns zero. I am going to test APERF & MPERF so that you don't need to do that from there. Please stay tuned. Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201104141044.55789.jkim>