From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [PATCH] conntrack: Reduce conntrack count in nf_conntrack_free() Date: Tue, 24 Mar 2009 16:21:43 +0100 Message-ID: <49C8FA87.2030106@trash.net> References: <49C77D71.8090709@trash.net> <49C780AD.70704@trash.net> <49C7CB9B.1040409@trash.net> <49C8A415.1090606@cosmosbay.com> <49C8CCF4.5050104@cosmosbay.com> <1237907850.12351.80.camel@sakura.staff.proxad.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Eric Dumazet , Joakim Tjernlund , avorontsov@ru.mvista.com, netdev@vger.kernel.org, "Paul E. McKenney" To: mbizon@freebox.fr Return-path: Received: from stinky.trash.net ([213.144.137.162]:36574 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751766AbZCXPVv (ORCPT ); Tue, 24 Mar 2009 11:21:51 -0400 In-Reply-To: <1237907850.12351.80.camel@sakura.staff.proxad.net> Sender: netdev-owner@vger.kernel.org List-ID: Maxime Bizon wrote: > On Tue, 2009-03-24 at 13:07 +0100, Eric Dumazet wrote: > >> We use RCU to defer freeing of conntrack structures. In DOS situation, >> RCU might accumulate about 10.000 elements per CPU in its internal >> queues. To get accurate conntrack counts (at the expense of slightly >> more RAM used), we might consider conntrack counter not taking into >> account "about to be freed elements, waiting in RCU queues". We thus >> decrement it in nf_conntrack_free(), not in the RCU callback. > > Your patch fixes the problem on my board too (embedded mips router > 250Mhz), thanks. > > Yet I'm concerned about what you said concerning RAM usage. I have a > very small amount on memory left on my board (less than 4M), and I tuned > ip route cache size and nf_conntrack_max to make sure I won't go OOM. > > With your patch, does it mean 10000 conntrack entries can be allocated > while nf_conntrack_max is say only 2048 ? Temporarily under worst-case circumstances, yes. Eric is already working on his proposed improvement though :)