Fix CPU hotplug IRQ migration
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 4 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 4 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/4] Fix CPU hotplug IRQ migration
Quoted 14 lines · Russell King - ARM Linux
Quoted 9 lines · Santosh Shilimkar
Will make you OMAP4 IRQ code available for this particular aspect and may be we can take it from there. There are two main problems I am seeing currently.
1)Which CPU gic_arch_extn_[mask/unmask] operate on? Can we assume that whichever CPU the call being executed should be the target CPU ? This might not be safe assumption though. For the extn, there is no other way to know the target CPU for mask/unmask of an IRQ
This goes back to the mistake that was made with the initial set of GIC PPI patches.
Quoted 7 lines
You can't assume anything about which CPU the mask/unmask functions end up running on. Between code calling
request_irq()and the relevant unmask function being called, we can end up scheduling, either because of a mutex being waited for or because of a preemption event. That means we can end up on a different CPU to that which we started out on.
Thanks for confirming the same.
Quoted 4 lines
So, the only thing you can do is remember the CPU number which it was last associated with - a simple 'unsigned int' should do in the extensions data structures, one per IRQ.
How do you build the per IRQ CPU association information? The point is fist mask/unmask call itself can be happening from a CPU which is not the target CPU for that IRQ.
We can do something like GIC init does. Mark all the IRQ's to boot CPU, save this info and keep using it in mask/unmask. This association can be changed by CPU hotplug or force IRQ affinity setting and we take care of updating the stored PER IRQ cpu association.
Quoted 10 lines
However, my point is that doing this:
gic_arch_extn.irq_set_affinity(d, cpumask_of(cpu), force);and then:
cpu = cpumask_first(affinity);in the extensions code is a very long winded way of communicating a single CPU number down into the IRQ extension code.
Agree. As you suggested , the GIC code recompose a CPU mask containing exactly one CPU and relaying that information with some custom function might be more efficient.
Regards
Santosh