Date: Wed, 20 Mar 2019 23:49:17 -0400 From: Mark Johnston <markj@freebsd.org> To: rgrimes@freebsd.org Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r345359 - in head/sys/cddl/dev/dtrace: amd64 i386 Message-ID: <20190321034917.GA8186@raichu> In-Reply-To: <201903210320.x2L3KIjc058579@gndrsh.dnsmgr.net> References: <201903210252.x2L2qMSP022374@repo.freebsd.org> <201903210320.x2L3KIjc058579@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 20, 2019 at 08:20:18PM -0700, Rodney W. Grimes wrote: > > Author: markj > > Date: Thu Mar 21 02:52:22 2019 > > New Revision: 345359 > > URL: https://svnweb.freebsd.org/changeset/base/345359 > > > > Log: > > Don't attempt to measure TSC skew when running as a VM guest. > > > > It simply doesn't work in general since VCPUs may migrate between > > physical cores. The approach used to measure skew also doesn't > > make much sense in a VM. > > "May" is the important aspect here, and to my knowledge both > bhyve and Vmware provide a way to pin cpus there should be > a way for us to turn this back on if it is desired. Sticking > it under the big knob vm_guest is probably not the most flexiable > solution. > > Could we please have someway to force this back on? Even with pinning the skew computation is bogus in a VM. On an idle host running bhyve with pinned vCPUs it gives offsets that are several orders of magnitude larger than on the host. I would prefer to see a specific reason for wanting the old behaviour before adding a knob.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190321034917.GA8186>