Re: [RFC PATCH 1/1] module: speed modprobe by adding name_crc to struct module

[Petr Pavlu <petr.pavlu@suse.com>]

On 1/23/26 12:46 AM, Jim Cromie wrote:
> "modprobe foo" currently does strcmp on the name, this can be improved.
> 
> So this commit:
> 
> 1. adds name_crc to struct module
> 2. modpost.c computes the value and
> 3. outputs it for "modinfo foo" to see/use.
> 
> 4. adds hotpath to find_module_all()
>    this uses name_crc to do quick "name-check"
>    falls back to strcmp only to guard against collisions.
> 
> This should significantly reduce modprobe workload, and shorten module
> load-time.
> 
> Since it alters struct module, its binary incompatible. This means:
> 
> 1. RFC for its wide "blast radius".
> 2. suitable for major version bump *only*
> 
> 3. it opens door for further struct module reorg, to:
>    a. segregate fields by "temperature"
>    b. pack out paholes.
>    c. improve cache locality (by reordering coldest on bottom)
>       name should be cold now.
>       bikeshedding is appropriate here.
> 
> NB: this isn't a substitute for CONFIG_MODULE_SIG.
> It reimplements crc_le(), doesn't reuse kernel's version.
> 
> CC: Luis Chamberlain <mcgrof@kernel.org>
> CC: Petr Pavlu <petr.pavlu@suse.com>
> CC: Daniel Gomez <da.gomez@kernel.org>
> CC: Sami Tolvanen <samitolvanen@google.com>
> CC: Aaron Tomlin <atomlin@atomlin.com>
> CC: linux-modules@vger.kernel.org
> 
> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
> 
>  '#' will be ignored, and an empty message aborts the commit.

This patch looks as if it were generated by AI. If so, please avoid
sending such changes. Otherwise, the commit description should explain
the affected workload. This should be backed up by actual measurements,
showing how the change improves the situation.

Implementation-wise, I don't think this is the right approach. If
searching by a module name is a hot operation, a hash table can be added
to speed it up.

-- 
Cheers,
Petr