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

[Alan Cox]

Doug Rabson wrote:
>
> 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.

I have seen presentations on this topic by AMDers: 
http://www.amd64.org/research/virtualization.html

However, what they are doing is making Linux spin locks adaptive so that 
they block using a new hypercall that tries to perform a directed yield 
of the CPU to the preempted lock holder.  However, the new hypercall can 
only guess at who the preempted lock holder is.

So, they are not yet worried about completely avoiding pointless 
spinning, because they first need to get over hump of non-adaptive spinning.

Alan