Re: Use of newer locking primitives...

[Paul Durrant <xadimgnik@xxxxxxxxx>]

On 30/08/2022 14:04, Martin Harvey wrote:
> -----Original Message-----
> From: Paul Durrant <xadimgnik@xxxxxxxxx>
>
>
> > Surely KeStallExecutionProcessor() is likely to HLT while waiting, so why is 
> > that going to be better than a yield?
> 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 
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/vmx/vmx.c;hb=HEAD#l4528
> > Also the yield is only done if the interlocked op fails, which it shouldn't do 
> > in the normal case.
> I'm trying to debug the *worst case* latency which is giving us trouble, not 
> the normal case.
>
> > It would be *really nice* to get vTune / uProf working on guests with all the 
> > uArchitecture counters working so we could actually find out exactly how many 
> > cycles get spent where.
> >
> > We see 99% of TxPollDpc's completing rapidly (microseconds), and then very 
> > occasionally we get a 4ms PollDpc. This is timing via ETW. If I get time to 
> > repro it (cpl of weeks), then I might try changing the stall mechanisms, and 
> > possibly the locking, separately.
> > 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... that's the lack of fairness I was referring to.
>
> Right OK. I'll have a go at this one on a "suck it and see" approach. I'm 
> assuming you'd be happy to take a look at approaches supported by some good profiling 
> data.
Yes. If there is still a copy of chariot lying around inside Citrix then 
some numbers from that would be good.
  Paul