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