[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1225002815.7654.487.camel@pasglop>
Date: Sun, 26 Oct 2008 17:33:35 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: David Miller <davem@...emloft.net>
Cc: galak@...nel.crashing.org, akpm@...l.org,
linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org,
torvalds@...l.org, maxk@...lcomm.com, tglx@...utronix.de
Subject: Re: [PATCH] genirq: Set initial default irq affinity to just CPU0
On Sat, 2008-10-25 at 21:04 -0700, David Miller wrote:
> But back to my original wonder, since I've always tipped off of this
> generic IRQ layer cpu mask, when was it ever defaulting to zero
> and causing the behvaior your powerpc guys actually want? :-)
Well, I'm not sure what Kumar wants. Most powerpc SMP setups actually
want to spread interrupts to all CPUs, and those who can't tend to just
not implement set_affinity... So Kumar must have a special case of MPIC
usage here on FSL platforms.
In any case, the platform limitations should be dealt with there or the
user could break it by manipulating affinity via /proc anyway.
By yeah, I do expect default affinity to be all CPUs and in fact, I even
have an -OLD- comment in the code that says
/* let the mpic know we want intrs. default affinitya is 0xffffffff ...
Now, I've tried to track that down but it's hard because the generic code
seem to have changed in many ways around affinity handling...
So it looks like nowadays, the generic setup_irq() will call
irq_select_affinity() when an interrupt is first requested. Unless
you set CONFIG_AUTO_IRQ_AFFINITY and implement your own
irq_select_affinity(), thus, you will get the default one which copies
the content of this global irq_default_affinity to the interrupt.
However it does that _after_ your IRQ startup() has been called
(yes, this is very fishy), and so after you did your irq_choose_cpu()...
This is all very messy, along with hooks for balancing and other confusing
stuff that I suspect keeps changing. I'll have to spend more time next
week to sort out what exactly is happening on powerpc and whether we
get our interrupts spread or not...
That's the downside of having more generic irq code I suppose: now people
keep rewriting half of the generic code with x86 exclusively in mind and
we have to be extra careful :-)
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists