[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ykas9iX/D3WURx8T@linutronix.de>
Date: Fri, 1 Apr 2022 09:42:46 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Javier Martinez Canillas <javierm@...hat.com>
Cc: "Ahmed S. Darwish" <a.darwish@...utronix.de>,
Ard Biesheuvel <ardb@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-efi <linux-efi@...r.kernel.org>,
Brian Masney <bmasney@...hat.com>, Al Stone <ahs3@...hat.com>,
Peter Robinson <pbrobinson@...il.com>,
Robbie Harwood <rharwood@...hat.com>,
Peter Jones <pjones@...hat.com>,
Alexander Larsson <alexl@...hat.com>,
Andrew Halaney <ahalaney@...hat.com>,
linux-rt-users@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2] efi: Allow to enable EFI runtime services by default
on RT
On 2022-04-01 00:19:57 [+0200], Javier Martinez Canillas wrote:
> > In case of (CONFIG_PREEMPT_RT=y && CONFIG_EFI_DISABLE_RUNTIME=n),
> > shouldn't we add a small message in the kernel log warning that EFI
> > runtime services are enabled for the RT kernel?
> >
> > In almost all HW, except custom ones with "verified" firmware, such a
> > warning would be useful... This is especially true since in the embedded
>
> I considered that as well but was not sure about what that message should be.
This makes sense and we had this in the past but dropped it for some
reason.
> Since it will be printed even on systems whose EFI firmwares do not
> have such long call times as the ones described in the commit that
> disabled the runtime services for RT.
>
> And in that case the warning may be misleading and make users believe
> that a problem exists, which might not be accurate.
Does this matter? The efi-rtc driver is known to cause latencies but it
does not happen if the driver is not used. The same is probably true for
efi-vars: It won't cause high latencies on _read_ but then a certain
number of bit flips during read _may_ lead to write+erase which will
cause higher latencies.
Having a warning at boot (similar to trace_printk's warning) with the
options listed that are known to case high latencies might be a help.
There are some options that nobody will argue about like LOCKDEP. Then
there are other like WATCHDOG or this one, where a debate might start ;)
> Best regards,
> Javier
Sebastian
Powered by blists - more mailing lists