On Thu, Nov 20, 2014 at 02:24:43PM +0000, Daniel Thompson wrote:
On 20/11/14 11:52, Lucas Stach wrote:
I've sent almost the same patch a while ago. At this time it was shot down due to fears of the measurements being too flaky to be useful with all that IRQ dance. While I don't think this is true (I did some measurements on a SOLO and a QUAD variants of the i.MX6 with the same workload, that were only minimally apart), I believe the IRQ affinity dance isn't the best way to handle this.
Cumulative statistics and time based sampling profilers should be fine either way since a delay before the interrupt the asserted on the affected core should have a low impact here.
One thing you're missing is that the interrupt latency for this can be horrific.
Firstly, remember that Linux processes one interrupt (per core) at a time. What this means is that if we have two cores running interrupts (eg, CPU 2 and CPU 3), and we raise a PMU interrupt on CPU 1 which is supposed to be for CPU 0, then we'll process the interrupt on CPU 1, and forward it to CPU 2. CPU 2 will then have it pending, but has to wait for the interrupt handler to complete before it can service it, where upon it forwards it to CPU 3. CPU 3 then goes through the same before forwarding it to CPU 0.
I also wonder how this works when you use perf record -a (from all CPUs.) If the sampling rate is high enough, will the interrupt be forwarded to the other CPUs? Has perf record -a been tested?