Re: conntrackd: questions about the new alarm implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux