On 2008/01/21 13:55, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > Max Kellermann wrote: > > I have had a look at your new alarm.c. I have a few questions about > > it: > > > > - Please explain why you now have 2048 (!) alarm queues, where the > > correct one is determined by hashing the alarm struct. I fail to > > imagine how this hashing might be useful. I can only see that it > > makes the code more complex and 2048 times slower - except for > > add_alarm(), which becomes a little bit faster, but there are only > > few add_alarm() invocations compared with get_next_alarm_run() and > > do_alarm_run(). > > This assumption is true for stats and sync-ftfw. However, it's not for > the sync-alarm implementation. The previous approach sucks up CPU in > add_alarm() with 25000 connections. Current the benchmarks report > smoother results. I wasn't aware that the alarm library has to scale up to so many alarm objects. Of course, linear search in a linked list is slow in these dimensions, but there *has* to be a better algorithm. I will send a patch as soon as I have time to think about that. Max - To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
