All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarek Poplawski <jarkao2@gmail.com>
To: "Paweł Staszewski" <pstaszewski@itcare.pl>
Cc: Eric Dumazet <dada1@cosmosbay.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Linux Network Development list <netdev@vger.kernel.org>
Subject: Re: weird problem
Date: Fri, 10 Jul 2009 16:47:54 +0200	[thread overview]
Message-ID: <20090710144754.GA25385@ami.dom.local> (raw)
In-Reply-To: <4A568444.7010307@itcare.pl>

On Fri, Jul 10, 2009 at 01:59:00AM +0200, Paweł Staszewski wrote:
> Today i make other tests with change of  
> /proc/sys/net/ipv4/rt_cache_rebuild_count and kernel 2.6.30.1
>
> And when rt_cache_rebuild_count is set to "-1" i have always load on  
> x86_64 machine approx 40-50% of each cpu where network card is binded by  
> irq_aff
>
> when rt_cache_rebuild_count is set to more than "-1" i have 15 to 20 sec  
> of 1 to 3% cpu and after 40-50% cpu
...

Here is one more patch for testing (with caution!). It adds possibility
to turn off cache disabling (so it should even more resemble 2.6.28)
after setting: rt_cache_rebuild_count = 0

I'd like you to try this patch:
1) together with the previous patch and "rt_cache_rebuild_count = 0"
   to check if there is still the difference wrt. 2.6.28; Btw., let
   me know which /proc/sys/net/ipv4/route/* settings do you need to
   change and why

2) alone (without the previous patch) and "rt_cache_rebuild_count = 0"

3) if it's possible to try 2.6.30.1 without these patches, but with
   default /proc/sys/net/ipv4/route/* settings, and higher
   rt_cache_rebuild_count, e.g. 100; I'm interested if/how long it
   takes to trigger higher cpu load and the warning "... rebuilds is
   over limit, route caching disabled"; (Btw., I wonder why you didn't
   mention about these or maybe also other route caching warnings?)

Regards,
Jarek P.
--- (debugging patch #2; apply to 2.6.30.1 or 2.6.29.6)

 net/ipv4/route.c |   16 +++++++++++-----
 1 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 278f46f..3d183cb 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1181,12 +1181,18 @@ restart:
 	} else {
 		if (chain_length > rt_chain_length_max) {
 			struct net *net = dev_net(rt->u.dst.dev);
-			int num = ++net->ipv4.current_rt_cache_rebuild_count;
-			if (!rt_caching(dev_net(rt->u.dst.dev))) {
-				printk(KERN_WARNING "%s: %d rebuilds is over limit, route caching disabled\n",
-					rt->u.dst.dev->name, num);
+
+			if (net->ipv4.sysctl_rt_cache_rebuild_count > 0) {
+				int num = ++net->ipv4.current_rt_cache_rebuild_count;
+
+				if (!rt_caching(net))
+					printk(KERN_WARNING
+					       "%s: %d rebuilds is over limit, "
+					       "route caching disabled\n",
+					       rt->u.dst.dev->name, num);
+
+				rt_emergency_hash_rebuild(net);
 			}
-			rt_emergency_hash_rebuild(dev_net(rt->u.dst.dev));
 		}
 	}
 

  reply	other threads:[~2009-07-10 14:48 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-25 16:06 weird problem Paweł Staszewski
2009-06-25 16:33 ` Paweł Staszewski
2009-06-25 17:18   ` Paweł Staszewski
2009-06-25 19:45     ` Paweł Staszewski
2009-06-25 20:18       ` Eric Dumazet
2009-06-25 22:23         ` Paweł Staszewski
2009-06-26  8:37         ` Jarek Poplawski
2009-06-26  9:05           ` Jarek Poplawski
2009-06-26 10:19             ` Eric Dumazet
2009-06-26 17:45               ` Paweł Staszewski
2009-06-26 17:57                 ` Paweł Staszewski
2009-06-30  6:40                 ` Jarek Poplawski
2009-06-30  8:35                   ` Paweł Staszewski
2009-06-30  8:36                     ` Paweł Staszewski
2009-07-08 22:34                       ` Jarek Poplawski
2009-07-09 23:14                         ` Paweł Staszewski
2009-07-09 23:59                           ` Paweł Staszewski
2009-07-10 14:47                             ` Jarek Poplawski [this message]
2009-07-11  6:24                               ` Jarek Poplawski
2009-07-13 23:26                                 ` Paweł Staszewski
2009-07-14 16:24                                   ` Jarek Poplawski
2009-07-15 20:15                                     ` Paweł Staszewski
2009-07-15 22:43                                       ` Jarek Poplawski
2009-07-16 11:01                                       ` Jarek Poplawski
  -- strict thread matches above, loose matches on Subject: below --
2003-10-14 11:00 Weird problem Jean-Rene Cormier
     [not found] ` <3F8BEAEB.1060005@Loudoun-Fairfax.com>
     [not found]   ` <1066136413.12935.43.camel@forbidden.cipanb.ca>
2003-10-14 15:31     ` Jeffrey Laramie
     [not found]     ` <3F8C1700.3070902@Loudoun-Fairfax.com>
2003-10-14 16:59       ` Jean-Rene Cormier
2003-10-14 17:49         ` Jeffrey Laramie

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=20090710144754.GA25385@ami.dom.local \
    --to=jarkao2@gmail.com \
    --cc=dada1@cosmosbay.com \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pstaszewski@itcare.pl \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.