[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20081001164013.f72036c9.akpm@linux-foundation.org>
Date: Wed, 1 Oct 2008 16:40:13 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Arjan van de Ven <arjan@...radead.org>
Cc: tglx@...utronix.de, linux-kernel@...r.kernel.org,
torvalds@...ux-foundation.org, mingo@...e.hu,
benh@...nel.crashing.org, rostedt@...dmis.org,
jonathan@...masters.org, sdietrich@...e.de
Subject: Re: [RFC patch 0/5] genirq: add infrastructure for threaded
interrupt handlers
On Wed, 1 Oct 2008 16:29:50 -0700
Arjan van de Ven <arjan@...radead.org> wrote:
> On Wed, 1 Oct 2008 16:23:33 -0700
> Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> >
> > I'm a bit surprised to see that there is no facility for per-cpu
> > interrupt threads?
> >
>
> per handler is the right approach (that way, if one dies, all other
> interrupts will likely keep working)
>
> now.. normally an interrupt only goes to one cpu, so effectively it is
> per cpu already anyway
Yes, if a) the thread was asleep when it was woken up and b) if the
scheduler does the right thing and wakes the thread on the CPU which
called wake_up().
The ongoing sagas of tbench/mysql/volanomark regressions make me think
that any behaviour which we "expect" of the scheduler should be
triple-checked daily :(
> we should however make the irq threads follow the affinity masks of the
> irq... that'd be an easy add-on and probably worthwhile.
--
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