From: Eric Dumazet <dada1@cosmosbay.com>
To: Jesper Dangaard Brouer <hawk@diku.dk>
Cc: "David S. Miller" <davem@davemloft.net>,
Robert Olsson <Robert.Olsson@data.slu.se>,
linux-net@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Kernel panic: Route cache, RCU, possibly FIB trie.
Date: Fri, 24 Mar 2006 07:11:56 +0100 [thread overview]
Message-ID: <44238DAC.2020402@cosmosbay.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0603232128400.3500@ask.diku.dk>
Jesper Dangaard Brouer a écrit :
>
> On Thu, 23 Mar 2006, Eric Dumazet wrote:
>
>> Jesper Dangaard Brouer a écrit :
>>
>>>> grep . /proc/sys/net/ipv4/route/*
>>>> /proc/sys/net/ipv4/route/error_burst:5000
>>>> /proc/sys/net/ipv4/route/error_cost:1000
>>>> grep: /proc/sys/net/ipv4/route/flush: Operation not permitted
>>>> /proc/sys/net/ipv4/route/gc_elasticity:8
>>>> /proc/sys/net/ipv4/route/gc_interval:60
>>>> /proc/sys/net/ipv4/route/gc_min_interval:0
>>>> /proc/sys/net/ipv4/route/gc_min_interval_ms:500
>>>> /proc/sys/net/ipv4/route/gc_thresh:65536
>>>> /proc/sys/net/ipv4/route/gc_timeout:300
>>>> /proc/sys/net/ipv4/route/max_delay:10
>>>> /proc/sys/net/ipv4/route/max_size:1048576
>>>> /proc/sys/net/ipv4/route/min_adv_mss:256
>>>> /proc/sys/net/ipv4/route/min_delay:2
>>>> /proc/sys/net/ipv4/route/min_pmtu:552
>>>> /proc/sys/net/ipv4/route/mtu_expires:600
>>>> /proc/sys/net/ipv4/route/redirect_load:20
>>>> /proc/sys/net/ipv4/route/redirect_number:9
>>>> /proc/sys/net/ipv4/route/redirect_silence:20480
>>>> /proc/sys/net/ipv4/route/secret_interval:600
>>
>> I would say : Change the settings :)
>>
>> echo 2 > /proc/sys/net/ipv4/route/gc_elasticity
>> echo 1 > /proc/sys/net/ipv4/route/gc_interval
>> echo 131072 > /proc/sys/net/ipv4/route/gc_thresh
>
> These parameters do not solve the problem. I think you missed my
> previous point. The parameter that needs adjustment is:
>
> /proc/sys/net/ipv4/route/max_size
>
> The garbage collector will not be activated before the number of entries
> are above "max_size" (see: function rt_garbage_collect).
>
> I have set:
> /proc/sys/net/ipv4/route/gc_thresh:30000
> /proc/sys/net/ipv4/route/max_size:30000
>
> Which solves the problem of the route cache growing too large too fast.
>
>
> I have read the route.c code again, to see if I missed something. Are
> you trying to make the function "rt_check_expire" to do the cleanup?
>
> I have tried your parameters, and it does not have the desired effect.
>
I was just guessing, since you didnt give us your rtstat output.
If you start to hit max_size then you have really a problem.
And no, I was not trying to make the garbage collector starts. This cost way
too much cpu, the router drops packets.
On my routers, I try to size the rt hash table appropriatly (boot param :
rhash_entries=1048575 for example), and keep the chains small, to avoid
spending too much cpu time (and too much memory cache lines touched) in
{soft}irq processing.
But yes it uses some memory.
# rtstat -c10 -i1
rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|
entries| in_hit|in_slow_|in_slow_|in_no_ro| in_brd|in_marti|in_marti|
out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis|
| | tot| mc| ute| | an_dst| an_src|
| _tot| _mc| | ed| miss| verflow| _search|t_search|
1672276| 32062| 4688| 0| 0| 0| 0| 0|
2124| 2176| 0| 0| 0| 0| 0| 26020| 4385|
1671142| 31826| 4626| 0| 0| 0| 0| 0|
2055| 1906| 0| 0| 0| 0| 0| 25617| 4124|
1670424| 31473| 4702| 0| 0| 0| 0| 0|
2221| 2144| 0| 0| 0| 0| 0| 25348| 4340|
1670928| 31671| 7600| 0| 0| 0| 0| 0|
2037| 2152| 0| 0| 0| 0| 0| 30354| 4245|
1670444| 31704| 4818| 0| 0| 0| 0| 0|
2037| 1927| 0| 0| 0| 0| 0| 25424| 3871|
1670133| 31785| 4598| 0| 0| 0| 0| 0|
1988| 2184| 0| 0| 0| 0| 0| 24946| 4302|
1669990| 31544| 4700| 0| 0| 0| 0| 0|
2022| 2188| 0| 0| 0| 0| 0| 25092| 4357|
1669880| 31930| 4750| 0| 0| 0| 0| 0|
2054| 2002| 0| 0| 0| 0| 0| 25703| 4214|
Eric
next prev parent reply other threads:[~2006-03-24 6:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-20 21:44 Kernel panic: Route cache, RCU, possibly FIB trie Jesper Dangaard Brouer
2006-03-20 22:09 ` Dipankar Sarma
2006-03-21 10:29 ` Jesper Dangaard Brouer
2006-03-21 10:37 ` David S. Miller
2006-03-21 14:51 ` Jesper Dangaard Brouer
2006-03-21 21:25 ` David S. Miller
2006-03-23 15:35 ` Jesper Dangaard Brouer
2006-03-23 15:44 ` Jesper Dangaard Brouer
2006-03-23 16:15 ` Eric Dumazet
2006-03-23 21:37 ` Jesper Dangaard Brouer
2006-03-24 6:11 ` Eric Dumazet [this message]
2006-03-24 10:34 ` Jesper Dangaard Brouer
2006-03-23 21:32 ` Robert Olsson
2006-03-21 13:28 ` Robert Olsson
2006-03-21 15:27 ` Jesper Dangaard Brouer
2006-03-21 15:37 ` Eric Dumazet
2006-03-21 15:43 ` Dipankar Sarma
2006-03-21 16:30 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44238DAC.2020402@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=Robert.Olsson@data.slu.se \
--cc=davem@davemloft.net \
--cc=hawk@diku.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox