Date: Thu, 5 Feb 2009 15:39:02 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Doug Rabson <dfr@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r188153 - user/dfr/xenhvm/6/sys/amd64/conf Message-ID: <alpine.BSF.2.00.0902051536300.71447@fledge.watson.org> In-Reply-To: <200902051509.n15F9gCj030370@svn.freebsd.org> References: <200902051509.n15F9gCj030370@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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... Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0902051536300.71447>