Dear Ard,
On 03/25/2018 09:41 AM, Paul Menzel wrote:
On 03/24/2018 11:35 PM, Ard Biesheuvel wrote:
On 24 March 2018 at 22:10, Paul Menzel wrote:
According to `initcall_debug`, `efisubsys_init` takes more than a few
milliseconds to execute on a Dell XPS 13 9370 (Intel(R) Core(TM)
i7-8550U CPU @ 1.80GHz).
```
[…]
[ 0.144474] calling efisubsys_init+0x0/0x2cf @ 1
[ 0.144474] Registered efivars operations
[ 0.173690] initcall efisubsys_init+0x0/0x2cf returned 0 after 27343
usecs
[…]
```
To get a vanilla Linux kernel to boot in well under one second, it’d
be nice
if the time could be improved. Do you know, why it takes so long?
According to `bootgraph.py` from pm-graph [1][2] it takes even a little
longer.
efisubsys_init: start=690.841, end=720.493, length(w/o overhead)=31.250
ms, return=0
There are several dozen calls to `virt_efi_get_next_variable()` all
but one
taking around 0.335 ms. This path needs to be optimized. Is that
possible?
That depends. These are firmware calls, so to make these calls faster,
you need to modify the firmware, not the kernel.
Yeah, unfortunately, no free firmware runs on this laptop, and Dell
doesn’t respond to these kind of reports, as they think, it’s not
important.
We may be able to make more intrusive changes to get rid of this
delay, e.g., spin up a special kernel thread, but I'd have to check in
more detail.
That’d be great.
In the mean time, you can try passing 'efi=noruntime' to the kernel.
Thank you, I didn’t know about that. Unfortunately, initcall_debug still
reports the same time although the one message is gone.
```
$ sudo dmesg | grep efisubsys
[ 0.145779] calling efisubsys_init+0x0/0x2cf @ 1
[ 0.172034] initcall efisubsys_init+0x0/0x2cf returned 0 after 27343 usecs
```
Hmm, it looks like, I only edited `/etc/default/grub` and didn’t run
`sudo update-grub`.
```
$ sudo dmesg | grep efisubsys
[ 0.776339] calling efisubsys_init+0x0/0x2cf @ 1
[ 0.776339] initcall efisubsys_init+0x0/0x2cf returned 0 after 0 usecs
```
To reproduce this, clone the pm-graph repository [2], use `sudo
./bootgraph.py -f -fstat -maxdepth 10 -manual` to see what to add to
`/boot/grub/grub.cfg`. Then reboot, and execute `sudo ./bootgraph.py -f
-fstat -maxdepth 10`.
If your system is powerful enough, you can use a higher maximum depth. I
didn’t get around how `-cgfilter` works to get smaller HTML files.
Kind regards,
Paul
[1] https://01.org/suspendresume
[2] https://github.com/01org/pm-graph
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
