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]

Date:	Sun, 18 Oct 2009 14:47:04 -0700
From:	Greg KH <greg@...ah.com>
To:	Alan Jenkins <sourcejedi.lkml@...glemail.com>
Cc:	carmelo73@...il.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

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.

> (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.

thanks,

greg k-h
--
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/