Messages in this thread | | | Subject | Re: [PATCH v2] irqchip/gic-v3-its: Balance initial LPI affinity across CPUs | From | John Garry <> | Date | Thu, 12 Mar 2020 16:27:57 +0000 |
| |
Hi Marc,
>>> When mapping a LPI, the ITS driver picks the first possible >>> affinity, which is in most cases CPU0, assuming that if >>> that's not suitable, someone will come and set the affinity >>> to something more interesting. >>> >>> It apparently isn't the case, and people complain of poor >>> performance when many interrupts are glued to the same CPU. >>> So let's place the interrupts by finding the "least loaded" >>> CPU (that is, the one that has the fewer LPIs mapped to it). >>> So called 'managed' interrupts are an interesting case where >>> the affinity is actually dictated by the kernel itself, and >>> we should honor this. >>> >>> Reported-by: John Garry <john.garry@huawei.com> >>> Link: >>> https://lore.kernel.org/r/1575642904-58295-1-git-send-email-john.garry@huawei.com >>> >>> Signed-off-by: Marc Zyngier <maz@kernel.org> >>> Cc: John Garry <john.garry@huawei.com> >>> Cc: Ming Lei <ming.lei@redhat.com> >>> --- >>> Reviving this at John's request. >> >> Thanks very much. I may request a colleague test this due to possible >> precautionary office closure. > > Huh. Not great... :-( > >> >> The major change is that the >>> affinity follows the x86 model, as described by Thomas. >> >> There seems to be a subtle difference between this implementation and >> what Thomas described for managed interrupts handling on x86. That >> being, managed interrupt loading is counted separately to total >> interrupts per CPU for x86. That seems quite important so that we >> spread managed interrupts evenly. > > Hmmm. Yes. That'd require a separate per-CPU counter. Nothing too invasive > though. I'll roll that in soon. I still wonder about interaction of > collocated > managed and non-managed interrupts, but we can cross that bridge later.
Great. And I think I may have mentioned this before (or I did and it was not a good idea), it now seems that we may be able to just leverage the generic matrix irq code here.
Cheers, John
| |