Re: [PATCH 2/2] module: add support to avoid duplicates early on load

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02.06.23 18:06, Linus Torvalds wrote:
On Fri, Jun 2, 2023 at 11:20 AM David Hildenbrand <david@xxxxxxxxxx> wrote:

What concerns me a bit, is that on the patched kernel we seem to hit more cases where
boot takes much longer (in both kernel configs).

So it potentially serializes the loads to the same file more, but in
the process uses much less memory (since the ones waiting will not
have done any of the "load file contents and uncompress them"). So
it's a bit of a trade-off.

I have the feeling that -- on this system -- it's some inaccurate accounting of firmware+loader times to the kernel startup time. Combined with some other noise. Especially the firmware loading time seems to be fairly randomized.

I guess what we care about regarding module loading is the initrd+userspace loading times, and they are fairly stable. But we mostly care about udev.

So let's look only at "systemd-udev" services:

1) !debug

a) master

5.672s systemd-udev-settle.service
 505ms systemd-udev-trigger.service
 272ms systemd-udevd.service
5.418s systemd-udev-settle.service
 487ms systemd-udev-trigger.service
 258ms systemd-udevd.service
5.707s systemd-udev-settle.service
 527ms systemd-udev-trigger.service
 273ms systemd-udevd.service
6.250s systemd-udev-settle.service
 455ms systemd-udev-trigger.service
 283ms systemd-udevd.service


b) patched

4.652s systemd-udev-settle.service
 461ms systemd-udev-trigger.service
 302ms systemd-udevd.service
4.652s systemd-udev-settle.service
 461ms systemd-udev-trigger.service
 302ms systemd-udevd.service
4.634s systemd-udev-settle.service
 444ms systemd-udev-trigger.service
 296ms systemd-udevd.service
4.745s systemd-udev-settle.service
 444ms systemd-udev-trigger.service
 273ms systemd-udevd.service


2) debug

a) master

32.806s systemd-udev-settle.service
 9.584s systemd-udev-trigger.service
  471ms systemd-udevd.service
29.901s systemd-udev-settle.service
 8.914s systemd-udev-trigger.service
  400ms systemd-udevd.service
28.640s systemd-udev-settle.service
 9.260s systemd-udev-trigger.service
  477ms systemd-udevd.service
29.498s systemd-udev-settle.service
 9.073s systemd-udev-trigger.service
  444ms systemd-udevd.service


b) patched

28.765s systemd-udev-settle.service
 8.898s systemd-udev-trigger.service
  400ms systemd-udevd.service
28.292s systemd-udev-settle.service
 8.903s systemd-udev-trigger.service
  401ms systemd-udevd.service
34.588s systemd-udev-settle.service
 8.959s systemd-udev-trigger.service
  455ms systemd-udevd.service
28.641s systemd-udev-settle.service
 8.953s systemd-udev-trigger.service
  389ms systemd-udevd.service



So except some noise, in the general case the patched version seems to be faster just looking at systemd-udev.


We could complicate things a bit, and let other callers return -EEXIST
a bit earlier, but I'm not convinced it really matters.

Looking at the numbers, agreed.


Honestly, taking too long because user space does something stupid and
wrong is not a kernel bug. Not booting because we use too much memory
- that's problematic. But booting slowly because udev does several
thousand unnecessary module loads is entirely on udev.

Yes.


I'll do some more experiments, but from what I can tell

Tested-by: David Hildenbrand <david@xxxxxxxxxx>

--
Cheers,

David / dhildenb





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux