[Top] [All Lists]

Re: Get rid of rt_check_expire and rt_garbage_collect

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: Get rid of rt_check_expire and rt_garbage_collect
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Sun, 3 Apr 2005 17:41:25 +1000
Cc: Eric Dumazet <dada1@xxxxxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev <netdev@xxxxxxxxxxx>, Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
In-reply-to: <1112475955.1088.294.camel@xxxxxxxxxxxxxxxx>
References: <E1DHdsP-0003Lr-00@xxxxxxxxxxxxxxxxxxxxxxxx> <424E641A.1020609@xxxxxxxxxxxxx> <20050402112304.GA11321@xxxxxxxxxxxxxxxxxxx> <1112475955.1088.294.camel@xxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
On Sat, Apr 02, 2005 at 04:05:55PM -0500, jamal wrote:
> > Here is how it can be done: Every time a routing entry is inserted into
> > a hash chain, we perform GC on that chain unconditionally.
> May not be a good idea to do it unconditionally - in particular on SMP
> where another CPU maybe spinning waiting for you to let go of bucket
> lock. In particular if a burst of packets accessing the same bucket show
> up on different processors, this would be aggravated.
> You may wanna kick in this algorithm only when things start going past a
> certain threshold.

This isn't too bad because:

1. The fast path is lockless using RCU.
2. The number of locks exceeds the number of CPUs by some insane amount.
3. The cost of performing GC is really cheap, it's just a matter of
calling rt_may_expire.

Anyway, I agree that all of these ideas are simply fantasy until
we have some code.  So let me work on that and then we can let the
benchmarks do the talking :)

Visit Openswan at
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page:
PGP Key:

<Prev in Thread] Current Thread [Next in Thread>