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. -- "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
