linux-kernel - Re: Fast LKM symbol resolution with SysV ELH hash table

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]

Message-ID: <2ccd6e3c0910190445va8ff4a8x94dc4044ac01057d@mail.gmail.com>
Date:	Mon, 19 Oct 2009 13:45:20 +0200
From:	Carmelo Amoroso <carmelo73@...il.com>
To:	Greg KH <greg@...ah.com>
Cc:	Alan Jenkins <sourcejedi.lkml@...glemail.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	linux-kbuild <linux-kbuild@...r.kernel.org>
Subject: Re: Fast LKM symbol resolution with SysV ELH hash table

2009/10/18 Greg KH <greg@...ah.com>:
> On Sun, Oct 18, 2009 at 01:44:04PM +0100, Alan Jenkins wrote:
>> Hypothetically: imagine we both finish our work and testing on the
>> same machine shows hash tables saving 100% and bsearch saving 90%.  In
>> absolute terms, hash tables might have an advantage of 0.03s on my
>> system (where bsearch saved 0.3s), and a total advantage of 0.015s for
>> the modules you tested (where hash tables saved ~0.15s).
>>
>> Would you accept bsearch in this case?  Or would you feel that the
>> performance of hash tables outweighed the extra memory requirements?
>
> The performance difference in "raw" time speed might be much different
> on embedded platforms with slower processors, so it might be worth the
> tiny complexity to get that much noticed speed.
>

yes, right. Further the figures I reported on the slides were taken
from a development
system with the rootfs mounted via NFS (no HDD or flash), with a debug
kernel and so on.

>> (This leaves the question of why you need to load 0.015s worth of
>> always-needed in-tree kernel code as modules.  For those who haven't
>> read the slides, the  reasoning is that built-in code would take
>> _longer_ to load.  The boot-loader is often slower at IO, and it
>> doesn't allow other initialization to occur in parallel).
>
> Distros are forced to build almost everything as modules.  I've played
> with building some modules into the kernel directly (see the openSUSE
> moblin kernels for examples of that), but when you have to suport a much
> larger range of hardware types and features that some users use and
> others don't, and the ability to override specific drivers by others due
> to manufacturer requests for specific updates, the need to keep things
> as modules is the only way to solve the problem.
>
> So I'm glad to see this speedup happen, very nice work everyone.
>

Just a few other notes. The current implementation I did based on SysV
has a drawback
that is not backward compatible, so you cannot use old modules with a kernel
with the option enabled due to changes on struct kernel_symbol.
Anyway I've just figured out how to change it to remove this limitation.
I need some time to review these patches.
Further, the newer implementation based on GNU hash which we are
working on right now,
will not require the extra .undef.hash ELF sections because hash
values are already embedded
into the GNU hash table, with a reduction in terms of footprint.

> thanks,
>
> greg k-h
>

Thanks to you too,
Carmelo
--
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/