Re: [Xen-devel] [RFC 08/16] gic: separate ppi processing

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

On 12/12/2018 12:52, Andrii Anisov wrote:
> On 12.12.18 14:46, Julien Grall wrote:
> > I haven't answered because I am waiting the numbers.
> I got it.
> But TBM will not show effect of this patch.
If TBM does not show effect, then you need a different benchmark. Probably by 
looking at how the PPI latency in Xen.
> Even the patch breaks TBM's 
> functionality because TBM relies on a phys timer interrupt to be assigned to the 
> domain (go through the spi path).
Well, the problem is your patch assumes PPI cannot be assigned to the guest. 
While this is the case today, there are plan for handing over PPI (such as 
timer) to guest. This will help to remove the hack we have for the timer in both 
Xen code base and Guest code base.
I would actually prefer if we try to optimize do_IRQ. Actually, this patch has 
some good ideas that can be re-used in the current code.
For instance, I think you can drop the logic that use _IRQ_PENDING because the 
interrupt can never be received to another PE while active (this will be cleared 
by desc->handler->end()).
Similarly the test on _IRQ_INPROGRESS could be dropped. Although, I would still 
like to keep set/clear _IRQ_INPROGRESS.
With those changes, do_IRQ becomes a lot more like the function do_ppi. The only 
difference is the spinlock. But I don't believe this will bring that much 
difference in performance impact. After all the lock should unlikely be contended.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel