lkml.org 
[lkml]   [2008]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.


\
 
 \ /
  Last update: 2008-09-15 23:53    [W:0.089 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site