Re: Use of newer locking primitives...

["Durrant, Paul" <xadimgnik@xxxxxxxxx>]

On 30/08/2022 19:01, Martin Harvey wrote:
> -----Original Message-----
> From: Paul Durrant <xadimgnik@xxxxxxxxx>
>
> > Nope. KeStallExecutionProcessor just pauses, it doesn't HLT, not interrupts 
> > required. It's a spin, so it does a PAUSE.
> > So directly equivalent to yield then. See
> 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. 
The Hyper-V enlightenments do define a 'long spin lock' limit so we 
could perhaps compromise by counting spins and then only yielding when 
we reach that limit.
>   
> > > Right, that could be because something has just dumped (or is still
> > dumping) a load of packets on the queue. Whoever has the lock has to drain the 
> > entire queue...
> Yes, isn't that funny? How could we change it?
Given that the queues are supposed to be per-vcpu I think we have to 
determine whether the current behaviour is actually bad in the normal 
case... Only the 'right' vcpu should be acquiring the lock for the queue.
> > Profiling ...
> We have iPerf. It seems to work with with ETW, and we have the other profilers 
> somewhat automated.
Ok, cool.

  Paul