On 4/21/23 20:31, Lucas De Marchi wrote: > On Fri, Apr 21, 2023 at 10:38:49AM -0700, Luis Chamberlain wrote: [...] >>> libkmod only skips the call if the module is already in >>> the live state. >> >> It can do better, it can converge requests to avoid a kernel_read*() >>from using vmalloc space. Note that this was not well known before, >> but now it is clear. > > in userspace, if using the same context and using init_module() rather > than finit_module(), I **guess** we would have a similar thing due to > the memory pool for modules: we don't read the module again. That is not > true for finit_module() though as we just open and pass the fd. > >> >> I realize though that this could mean sharing a context between all >> loads thoughs in udev, and such a change could take significant time >> and review to complete. > > But there is only one context. There aren't multiple paralell requests > from multiple sources. Probably need to Cc someone still changing > udev's builtin... but from a quick look, from what I remember about > that the last time I touched it and without data to prove me wrong, > it seems we are not looking at the right problem space to come up with a > solution. My understanding is that udev workers are forked. An initial kmod context is created by the main udevd process but no sharing happens after the fork. It means that the mentioned memory pool logic doesn't really kick in. Multiple parallel load requests come from multiple udev workers, for instance, each handling an udev event for one CPU device and making the exactly same requests as all others are doing at the same time. The optimization idea would be to recognize these duplicate requests at the udevd/kmod level and converge them. Cheers, Petr
