[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.