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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list