On 4/4/2015 2:34 AM, Ingo Molnar wrote:
Well, as a starter, if you can reproduce it on a system (I cannot),
How many cores does your current test system have, Ingo? I remember that
I did not see this on a machine with 24 cores, but did see it on one
with 36. My initial thought was that it mig
* Jesse Brandeburg wrote:
> > Now this is just a small annoyance that should not really matter -
> > it would be nice to figure out the real reason for why the irqs
> > move back to CPU#0.
> >
> > In theory the same could happen to 'irqbalanced' as well, if it
> > calls shortly after an irq
On Fri, 3 Apr 2015 08:55:57 +0200
Ingo Molnar wrote:
> So the original commit also has the problem that it unnecessary
> drops/retakes the descriptor lock:
>
> > irq_put_desc_unlock(desc, flags);
> > - /* set the initial affinity to prevent every interrupt being on CPU0 */
> > - if (m)
>
* Jesse Brandeburg wrote:
> I've seen a couple of reports of issues since commit e2e64a932556 ("genirq:
> Set initial affinity in irq_set_affinity_hint()") where the
> affinity for the interrupt when programmed via
> /proc/irq//smp_affinity will not be able to stick. It changes back
> to some p
4 matches
Mail list logo
