[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120626.004658.2123525722448546355.davem@davemloft.net>
Date: Tue, 26 Jun 2012 00:46:58 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: eric.dumazet@...il.com
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH] ipv4: Remove unnecessary code from rt_check_expire().
From: Eric Dumazet <eric.dumazet@...il.com>
Date: Tue, 26 Jun 2012 09:39:58 +0200
> On Tue, 2012-06-26 at 00:21 -0700, David Miller wrote:
>> IPv4 routing cache entries no longer use dst->expires, because the
>> metrics, PMTU, and redirect information are stored in the inetpeer
>> cache.
>>
>> Signed-off-by: David S. Miller <davem@...emloft.net>
>> ---
>>
>> Eric, when you did commit 9f28a2fc0bd77511f649c0a788c7bf9a5fd04edb
>> (ipv4: reintroduce route cache garbage collector) do you remember
>> if the thing we needed was the real expiry or both the
>> rt_is_expired() and the rt_may_expire() cases?
>>
>> I really want to remove rt_may_expire() from this conditional because
>> it results in absolutely stupid behavior. If your system is idle
>> for 5 minutes, all of your input routing cache entries are purged.
>
> Hmm, after a DDOS, purging all those routing cache entries in 5 minutes
> is good to recover some Mbytes of kernel memory.
And for legitimate traffic it's completely the wrong thing to do.
There is absolutely zero reason to pure valid entries when hash chains
average length of one.
I've been monitoring routing cache activity, and it's the height of
stupidity. Every 5 minutes we pure, and then they all get regenerated
again.
Routing cache entries are expensive to recreate, it's much easier to
just keep them around then to potentially eat four full trie lookups
because that's what it will cost to reconstitute those guys.
But regardless, could you actually answer the question I asked of you?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists