[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20100314232507.9901f37d.akpm@linux-foundation.org>
Date: Sun, 14 Mar 2010 23:25:07 -0400
From: Andrew Morton <akpm@...ux-foundation.org>
To: Jamie Lokier <jamie@...reable.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
u.kleine-koenig@...gutronix.de, a.p.zijlstra@...llo.nl,
andrea.gallo@...ricsson.com, dbrownell@...rs.sourceforge.net,
eric.y.miao@...il.com, hugh.dickins@...cali.co.uk,
John Stultz <johnstul@...ibm.com>, linux@...mer.net,
nico@...vell.com, Rusty Russell <rusty@...tcorp.com.au>,
Greg KH <greg@...ah.com>, David Miller <davem@...emloft.net>
Subject: Re: [patch 2/3] genirq: warn about IRQF_SHARED|IRQF_DISABLED at the
right place
On Mon, 15 Mar 2010 02:52:49 +0000 Jamie Lokier <jamie@...reable.org> wrote:
> Andrew Morton wrote:
> > We can tweak and tune until we're blue in the face, but the system's
> > IRQ latency will always be worse if handlers always run with interrupts
> > disabled.
>
> Are you sure?
>
> If good, fast irq handler A runs with interrupts enabled,
> and good, fast irq handler B runs (interrupting A),
> A's latency goes _up_ not down.
>
> If B happens first, then you get B's latency going up, and A's latency going down.
If the hardware doesn't prioritise these interrupts then the programmer
can do so crudely, by running the critical one with interrupts disabled.
--
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