On 06/14/2011 10:47 AM, Ed W wrote: > On 13/06/2011 03:50, Rich Felker wrote: >> On Thu, Apr 07, 2011 at 08:31:23PM +0100, Ed W wrote: >>> Obviously fixing iptables is desirable, but is it possible to improve >>> performance >> >> I think your time would be much better spent adding a sane version of >> iptables (without the hideous dlopen abomination) to Busybox. Then the >> problem would be a non-issue. > > Ahead of you already (kind of). If you check the iptables mailing lists > you will see that the latest iptables is now free of near all excess > modprobe calls bar a single initial call. > > However, I disagree with your point. Busybox contains an implementation > of modprobe which is gaspingly slow. Now we can:
Busybox modprobe used to be utterly slow before I rewrote it quite a while ago; the speed up from original code was 10-100x already at the time. :) However, at the time I wanted to maintain compatibility with module-init-tools and ended up using the same text file formats. See below. > Or we could notice that an alternative implementation of modprobe is > some 10-100x faster and consider that the busybox implementation is > possibly suboptimal? And not long after that, module-init-tools implemented binary file formats that can be used to do quicker lookups for modprobe names. I never bothered to implement that. The implementation is "sub-optimal" because it adheres to the old file formats of module-init-tools. It involves reading the large alias files for each program invocation. Adding support for the binary file formats used by the current module-init-tools would fix the performance issues. > Sure -ENOPATCH. But that's also because I have not developed in busybox > and please show a touch of compassion that I have spent some hours > poking around trying to benchmark where the problem might lay. Seems at > present like it's not clear whether I'm barking up the wrong tree that > it's the read() calls vs needing to read the binary files? Yes. The difference is that module-init-tools used to be dog slow too. And we wanted to maintain compatibility with file formats. This means that we need to read() and *a lot* of files with *a lot* of text. module-init-tools folks figured this out too, and they also generate a binary "binary hash file" in addition to the text mode files. These files are about the same size or larger then the text format, so now the generated dependency data from module-init-tools more than doubled. Though, apparently the text-only mode files are no longer really needed. See also depmod(8). > Perhaps folks could humour me a little and we could at least understand > where the performance problem comes from? In short: 1. module-init-tools sucked too 2. bb modprobe cloned form that 3. module-init-tools changed things a lot 4. no one has updated bb modprobe > Please note that my kernel is almost completely kernel module free - I'm > trying to solve a performance problem when there aren't any modules > being loaded... - Timo _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
