debian/changelog | 12 +++++++++++ net/ipv4/route.c | 57 +++++++++++++++++-------------------------------------- 2 files changed, 30 insertions(+), 39 deletions(-)
New commits: commit d9bf1062103725e9a0917e7a39eeab25f11d22ee Author: Stephen Hemminger <[email protected]> Date: Tue May 26 09:38:00 2009 -0700 2.6.29-4+vyatta+4 commit f7fbe9e90d1b2c8c5437d5e453365c8c3941fac4 Author: Anton Blanchard <[email protected]> Date: Mon Apr 27 05:42:24 2009 -0700 ipv4: Limit size of route cache hash table Right now we have no upper limit on the size of the route cache hash table. On a 128GB POWER6 box it ends up as 32MB: IP route cache hash table entries: 4194304 (order: 9, 33554432 bytes) It would be nice to cap this for memory consumption reasons, but a massive hashtable also causes a significant spike when measuring OS jitter. With a 32MB hashtable and 4 million entries, rt_worker_func is taking 5 ms to complete. On another system with more memory it's taking 14 ms. Even though rt_worker_func does call cond_sched() to limit its impact, in an HPC environment we want to keep all sources of OS jitter to a minimum. With the patch applied we limit the number of entries to 512k which can still be overriden by using the rt_entries boot option: IP route cache hash table entries: 524288 (order: 6, 4194304 bytes) With this patch rt_worker_func now takes 0.460 ms on the same system. Signed-off-by: Anton Blanchard <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 5ff3a284d179d3a661a07f8d0c486a6449108396 Author: Eric Dumazet <[email protected]> Date: Tue May 19 20:14:28 2009 +0000 net: fix rtable leak in net/ipv4/route.c Alexander V. Lukyanov found a regression in 2.6.29 and made a complete analysis found in http://bugzilla.kernel.org/show_bug.cgi?id=13339 Quoted here because its a perfect one : begin_of_quotation 2.6.29 patch has introduced flexible route cache rebuilding. Unfortunately the patch has at least one critical flaw, and another problem. rt_intern_hash calculates rthi pointer, which is later used for new entry insertion. The same loop calculates cand pointer which is used to clean the list. If the pointers are the same, rtable leak occurs, as first the cand is removed then the new entry is appended to it. This leak leads to unregister_netdevice problem (usage count > 0). Another problem of the patch is that it tries to insert the entries in certain order, to facilitate counting of entries distinct by all but QoS parameters. Unfortunately, referencing an existing rtable entry moves it to list beginning, to speed up further lookups, so the carefully built order is destroyed. For the first problem the simplest patch it to set rthi=0 when rthi==cand, but it will also destroy the ordering. end_of_quotation Problematic commit is 1080d709fb9d8cd4392f93476ee46a9d6ea05a5b (net: implement emergency route cache rebulds when gc_elasticity is exceeded) Trying to keep dst_entries ordered is too complex and breaks the fact that order should depend on the frequency of use for garbage collection. A possible fix is to make rt_intern_hash() simpler, and only makes rt_check_expire() a litle bit smarter, being able to cope with an arbitrary entries order. The added loop is running on cache hot data, while cpu is prefetching next object, so should be unnoticied. Reported-and-analyzed-by: Alexander V. Lukyanov <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Acked-by: Neil Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=d9bf1062103725e9a0917e7a39eeab25f11d22ee http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=f7fbe9e90d1b2c8c5437d5e453365c8c3941fac4 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=5ff3a284d179d3a661a07f8d0c486a6449108396 _______________________________________________ svn mailing list [email protected] http://mailman.vyatta.com/mailman/listinfo/svn
