svn commit: r188153 - user/dfr/xenhvm/6/sys/amd64/conf

Robert Watson rwatson at FreeBSD.org
Thu Feb 5 07:39:03 PST 2009


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


More information about the svn-src-user mailing list