Messages in this thread | | | Date | Mon, 15 Sep 2008 16:50:53 -0500 | From | Dean Nelson <> | Subject | Re: [RFC 0/4] dynamically allocate arch specific system vectors |
| |
On Sun, Sep 14, 2008 at 05:35:22PM +0200, Ingo Molnar wrote: > > * Dean Nelson <dcn@sgi.com> wrote: > > > On Mon, Aug 11, 2008 at 12:39:22PM -0700, Eric W. Biederman wrote: > > > > > > Although I am not at all convinced that dynamic allocation of > > > the vector number (instead of statically reserving it makes sense). > > > > We (SGI) need somewhere around eight vectors. > > > > There are two kernel modules, sgi-gru and sgi-xp (in drivers/misc), > > that each need two vectors. And there's the broadcast assist unit > > (BAU) that is involved in tlb shootdown on uv, which currently uses > > statically reserved vector 0xf8 (UV_BAU_MESSAGE -- see uv_bau_init()). > > while i understand the UV_BAU_MESSAGE case (TLB flushes are special), > why does sgi-gru and sgi-xp need to go that deep? They are drivers, they > should be able to make use of an ordinary irq just like the other 2000 > drivers we have do.
The sgi-gru driver needs to be able to allocate a single irq/vector pair for all CPUs even those that are not currently online. The sgi-xp driver has similar but not as stringent needs.
The current __assign_irq_vector() restricts the allocation of the irq/vector pair to a single CPU and its vector_allocation_domain().
> > I know of a debugger that also uses 0xf8 because it was previously > > available until UV_BAU_MESSAGE came along. The BAU would be happy with > > a dynamically allocated system vector. We have a couple of other > > things in the works that also need vectors. > > which debugger is this?
KDB.
| |