linux-kernel - Re: [PATCH V2 2/2] module: Fix performance regression on modules with large symbol tables

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 20 Nov 2011 22:29:55 -0800
From:	Kevin Cernekee <cernekee@...il.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Jan Beulich <JBeulich@...e.com>, linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 2/2] module: Fix performance regression on modules with
 large symbol tables

On Sun, Nov 20, 2011 at 9:06 PM, Rusty Russell <rusty@...tcorp.com.au> wrote:
> On Thu, 17 Nov 2011 19:15:02 -0800, Kevin Cernekee <cernekee@...il.com> wrote:
> I'm deeply tempted.  It's very simple, 46 lines shorter, preserves exact
> matches, and doesn't have any strange slowdowns on corner cases.

Unfortunately, the last patch I posted still makes duplicate copies of
the exact matches.  And the copy of nvidia.ko I'm looking at right now
does reuse strtab entries for the duplicated symbols.

FWIW, preserving exact matches would save about 35KB on a kernel
module whose .text + .data + .rodata sections add up to ~9.5MB.

I'm sure there are more clever ways to do it, but a fast brute force
approach could involve storing the core_strtab offsets in a temporary
array indexed by the original strtab st_name values.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/