Date: Thu, 5 Feb 2009 16:10:54 +0000 From: Doug Rabson <dfr@rabson.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Doug Rabson <dfr@FreeBSD.org>, src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r188153 - user/dfr/xenhvm/6/sys/amd64/conf Message-ID: <75E8FE57-7235-4F4D-813B-41BEFE7907C5@rabson.org> In-Reply-To: <alpine.BSF.2.00.0902051536300.71447@fledge.watson.org> References: <200902051509.n15F9gCj030370@svn.freebsd.org> <alpine.BSF.2.00.0902051536300.71447@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 Feb 2009, at 15:39, Robert Watson wrote: > > On Thu, 5 Feb 2009, Doug Rabson wrote: > >> Adaptive mutex spinning turns out to be very slightly slower on >> Xen, probably >> due to scheduling conflicts with other guests within the same >> hypervisor. > > Part of the effectiveness of adaptive mutexes is in their being able > to tell with a single read whether or not the thread owning the lock > is (likely) in execution. This is complicated with a hypervisor > because although the FreeBSD kernel has the thread in the run state > doesn't mean that the hypervisor has FreeBSD in the run state. Is > there any way we could provide similar hints here? As core density > goes up, people may over-commit hardware resources less, using Xen > for assigning subsets of the core pool to particular VMs as opposed > to time-sharing individual cores, in which case we'd like adaptive > mutexes to work... This is indeed the key problem. At least with Xen, there is no way of telling that the vcpu which is ostensibly executing the lock owning thread is actually scheduled onto a physical cpu by the hypervisor. Its something I will encourage the Xen people to improve on in future.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?75E8FE57-7235-4F4D-813B-41BEFE7907C5>