On Wed, Apr 19, 2023 at 04:32:30PM -0700, Luis Chamberlain wrote: > > It's not "wasted", as it is returned when the module is determined to be > > a duplicate. Otherwise everyone will want this enabled as they think it > > will actually save memory. > > I'll change the language to be clear the issue is memory pressure early > on boot. I'll also add a bit of language to help at least guide people > to realize that the real value-add for this, ie, I'll have to mention we > suspect issue is udev and not module auto-loading and that this however > may still help find a few cases we can optimize for. This isn't udev's "problem", all it is doing is what the kernel asked it to do. The kernel said "Here's a new device I found, load a module for it please!" And it's the kmod code here, not udev itself doing all of this. Why not just rate-limit it in userspace if your system can't handle 10's of thousands of kmod calls all at once? I think many s390 systems did this decades ago when they were controlling 10's of thousands of scsi devices and were hit with "device detection storms" at boot like this. If you really think it's the kernel's fault, just slow down the kernel's device detection code for the specific bus that is having problems. We've worked hard to make the kernel boot really fast and device detection happen in parallel, maybe that wasn't a good idea for some systems and so they need to boot slower. If so, then just turn off the parallel probing for the offending bus type. What specific devices and bus types are the problem here for these systems? thanks, greg k-h
