From: Greg KH <gregkh@linuxfoundation.org>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: david@redhat.com, patches@lists.linux.dev,
linux-modules@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, pmladek@suse.com,
petr.pavlu@suse.com, prarit@redhat.com,
torvalds@linux-foundation.org, rafael@kernel.org,
christophe.leroy@csgroup.eu, tglx@linutronix.de,
peterz@infradead.org, song@kernel.org, rppt@kernel.org,
dave@stgolabs.net, willy@infradead.org, vbabka@suse.cz,
mhocko@suse.com, dave.hansen@linux.intel.com,
colin.i.king@gmail.com, jim.cromie@gmail.com,
catalin.marinas@arm.com, jbaron@akamai.com,
rick.p.edgecombe@intel.com
Subject: Re: [PATCH] module: add debugging auto-load duplicate module support
Date: Thu, 20 Apr 2023 07:32:10 +0200 [thread overview]
Message-ID: <ZEDOWi8ifghwmOjp@kroah.com> (raw)
In-Reply-To: <ZEB6DmF+l3LVrpFI@bombadil.infradead.org>
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
next prev parent reply other threads:[~2023-04-20 5:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 20:46 [PATCH] module: add debugging auto-load duplicate module support Luis Chamberlain
2023-04-19 7:15 ` Greg KH
2023-04-19 23:32 ` Luis Chamberlain
2023-04-20 5:32 ` Greg KH [this message]
2023-04-20 21:03 ` Luis Chamberlain
2023-04-21 15:12 ` Greg KH
2023-04-21 16:42 ` Lucas De Marchi
2023-04-21 17:38 ` Luis Chamberlain
2023-04-21 18:31 ` Lucas De Marchi
2023-04-21 18:45 ` Luis Chamberlain
2023-04-26 10:13 ` Petr Pavlu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZEDOWi8ifghwmOjp@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=catalin.marinas@arm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=colin.i.king@gmail.com \
--cc=dave.hansen@linux.intel.com \
--cc=dave@stgolabs.net \
--cc=david@redhat.com \
--cc=jbaron@akamai.com \
--cc=jim.cromie@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=mhocko@suse.com \
--cc=patches@lists.linux.dev \
--cc=peterz@infradead.org \
--cc=petr.pavlu@suse.com \
--cc=pmladek@suse.com \
--cc=prarit@redhat.com \
--cc=rafael@kernel.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rppt@kernel.org \
--cc=song@kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).