Re: Use of newer locking primitives...

[Paul Durrant <xadimgnik@xxxxxxxxx>]

On 01/09/2022 10:25, Martin Harvey wrote:
> -----Original Message-----
> From: Durrant, Paul <xadimgnik@xxxxxxxxx>
>
> > > Ouch. Pause is one of the optional vmexit instructions. So you do an entire 
> > > vm-exit, when all you wanted to do is sit on your backside for a few 
> > > nanoseconds.
> > Well, arguably the guest is being a better citizen by exiting. If we really 
> > want to be a potential CPU hog then we could remove the yield.
> Well, here's the thing - we might be less of a CPU hog by doing the pause, and 
> letting the HW decide whether it wants to do its conditional vmexit, via some 
> trap. The specs say what they say, but the HW implementors will know the 
> details of how many cycles everything takes, and one would hope that they've 
> put something smart in to decide whether a pause does in fact trap and vmexit. 
> One would hope that executing multiple pauses in a row would be enough of a 
> clue.
Since I now look at the SDM I indeed see the PLE feature... which TBH 
was a feature I was not aware of. I note that Xen sets the gap and 
window to 128 and 4096, different from the 'long spin lock' 
enlightenment (CPUID 0x40000004:EBX) default value of 2047.
So, yes, let's just change all the explicit yields to _mm_pause() and 
take advantage.
  Paul