[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20241120073637.iwQyy4q7@linutronix.de>
Date: Wed, 20 Nov 2024 08:36:37 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Clark Williams <clark.williams@...il.com>
Cc: Clark Williams <clrkwllms@...nel.org>,
Huacai Chen <chenhuacai@...nel.org>,
Huacai Chen <chenhuacai@...ngson.cn>,
Xuerui Wang <kernel@...0n.name>, loongarch@...ts.linux.dev,
Steven Rostedt <rostedt@...dmis.org>,
linux-rt-devel@...ts.linux.dev, Guo Ren <guoren@...nel.org>,
Jiaxun Yang <jiaxun.yang@...goat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] LoongArch: Allow to enable PREEMPT_RT
On 2024-11-20 02:17:53 [+0000], Clark Williams wrote:
> On Mon, Nov 18, 2024 at 7:37 AM Sebastian Andrzej Siewior <
> bigeasy@...utronix.de> wrote:
>
> > On 2024-11-14 08:43:21 [-0600], Clark Williams wrote:
> > > We see similar problems with chronyd accessing the RTC on aarch64
> > > systems that use UEFI. Accessing anything via the EFI Runtime is very
> > > slow. Probably going to turn off 'rtcsync' in chronyd when running
> > > low-latency workloads.
> >
> > But isn't "we call into EFI and have no clue what happens" exactly the
> > reason why we disable EFI runtime services?
> >
> >
> I've had customers want access to EFI variables. I believe we default EFI
> runtime to be off and allow it to be turned on.
So the efi-rtc is accessed via functions calls into EFI. So you call in
there and they do (probably) access the RTC via i2c and remain in EFI
(block) for the entire process. That is why the access is disabled. The
difference here is that the bus access is slow so every read/ write
seems to take a while.
The EFI variable access by itself is fine however the variables might be
saved in NAND flash. The write access may trigger an erase process and
relocate the data and so may the read if too many bit flips were
detected.
> Clark
Sebastian
Powered by blists - more mailing lists