Jon Masters wrote:

On Mon, 2008-10-13 at 10:24 -0400, Jon Masters wrote:

On Mon, 2008-10-13 at 16:10 +0200, Jakub Jelinek wrote:


FYI, here is a tiny incremental fix for the patch I've posted earlier
- Mandriva folks reported that with my patch depmod was upset when run
on a tree with no modules at all.

Though if we ever manage to "demodularize for the win" to that point,
well, it'll be quite exciting!

I'm testing your 3.4.1 patch against today's 3.5 tree and will followup
with some results. Whichever performs best, I'll keep. Sorry I didn't
sort this out sooner, but it's time to move forward and get this sorted
out - and there are more trivial fixes I've got in mind. As of today's
rawhide there are also no longer any Fedora-specific patches left.


In one test, I ran modprobe about 8000 times on a desktop.

older modprobe: 190.03user 25.19system 3:55.54elapsed 91%CPU
upstream modprobe: 8.65user 19.69system 0:31.08elapsed 91%CPU
Jakob's modprobe: 6.71user 18.05system 0:27.01elapsed 91%CPU

The latter two vie a little between each other, but basically are
comparable. So for now, I'll keep upstream as it is and do some more
testing/write some scripts. Then I'll do some migration to unlocked
non-threaded functions and pull in other parts of Jakob's patch. I'm
thinking there are actually other places to focus on now - more
profiling will be called for and I'll push some more updates.

Older modprobe is 3.4.1, upstream is 3.5 (radix trie implementation),
Jakob's patch uses a hashtable/bucket mechanism.

Jon.




modprobe is mostly disk I/O bound, so for benchmarking the disk cache has to be
cleared before every run


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Thu, 2008-10-16 at 14:49 +0200, Harald Hoyer wrote:

> modprobe is mostly disk I/O bound, so for benchmarking the disk cache has to be
> cleared before every run

Nah. We're not making any claims about magically being able to speed up
the reading/module init itself, only the parsing of the meta data. At
udev coldstart time, the (small) files are likely sitting in the page
cache already anyway. I'm not so worried about how long udev/modprobe
takes once you've booted and insert your $whatever_random_device.

Your point is noted, and I will investigate further, but I'm pretty
convinced that we've got a dramatic speedup here either way. I'll be
pushing a 3.6 release ensuring that the binary files have a version
attached so I can make changes to the format in the future and then
fallback to the text versions of those files automatically.

Cheers,

Jon.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list