[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2104090041400.65251@angie.orcam.me.uk>
Date: Fri, 9 Apr 2021 00:45:13 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Masami Hiramatsu <mhiramat@...nel.org>
cc: Jisheng Zhang <Jisheng.Zhang@...aptics.com>,
Jisheng Zhang <jszhang3@...l.ustc.edu.cn>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Guo Ren <guoren@...ux.alibaba.com>,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] riscv: keep interrupts disabled for BREAKPOINT
exception
On Fri, 9 Apr 2021, Masami Hiramatsu wrote:
> > > Is this approach guaranteed to keep interrupt handling latency low enough
> > > for the system not to be negatively affected, e.g. for the purpose of NTP
> > > timekeeping?
> >
> > IMHO, interrupt latency can't be ensured if kprobes is triggered.
>
> Indeed. The latency depends on what the kprobe user handler does. Of course
> it must be as minimal as possible... On x86, it is less than a few microseconds.
> Thus it may be a jitter on hard realtime system, but not a big issue on
> usual system like NTP timekeeping.
Ack. Assuming that the breakpoint exception will only disable interrupts
if kprobes are in use it seems reasonable to me.
Thanks for double-checking.
Maciej
Powered by blists - more mailing lists