Max Kellermann wrote: > 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. Sure. Current approach gives good results to my benchmarks and I can make peace since it's not linear anymore ;). > I will send a patch as soon as I have time to think about that. Great. I bet that this will be a win for conntrackd. -- "Los honestos son inadaptados sociales" -- Les Luthiers - 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
