[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210220070808.GA7874@allandria.com>
Date: Fri, 19 Feb 2021 23:08:08 -0800
From: Brad Boyer <flar@...andria.com>
To: Finn Thain <fthain@...egraphics.com.au>
Cc: Arnd Bergmann <arnd@...nel.org>,
"Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"arnd@...db.de" <arnd@...db.de>,
"geert@...ux-m68k.org" <geert@...ux-m68k.org>,
"funaho@...ai.org" <funaho@...ai.org>,
"philb@....org" <philb@....org>, "corbet@....net" <corbet@....net>,
"mingo@...hat.com" <mingo@...hat.com>,
"linux-m68k@...ts.linux-m68k.org" <linux-m68k@...ts.linux-m68k.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] IRQ handlers run with some high-priority interrupts(not
NMI) enabled on some platform
On Sat, Feb 20, 2021 at 05:32:30PM +1100, Finn Thain wrote:
> Nope. Interrupt priority masking is there to place an upper bound
> interrupt latency. That's why this feature is shipping in contemporary
> hardware (e.g. ARM GIC). If you care about real time workloads on arm64,
> that may interest you.
I don't know if it's still true today, but in the past there was a very
noticeable difference in timer stability between the 68k macintosh
models with the timer interrupt at IPL 1 as compared to the models
where the timer interrupt was at IPL 6. The ability to preempt the
other interrupt handlers made the difference between a usable clock
and one that was pretty unreliable.
Brad Boyer
flar@...andria.com
Powered by blists - more mailing lists