From patchwork Fri Jul 10 14:47:54 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jarek Poplawski X-Patchwork-Id: 29682 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@bilbo.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from ozlabs.org (ozlabs.org [203.10.76.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ozlabs.org", Issuer "CA Cert Signing Authority" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id 252FFB7080 for ; Sat, 11 Jul 2009 00:48:19 +1000 (EST) Received: by ozlabs.org (Postfix) id 18C91DDDFB; Sat, 11 Jul 2009 00:48:19 +1000 (EST) Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id 807AFDDDFA for ; Sat, 11 Jul 2009 00:48:18 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753974AbZGJOsL (ORCPT ); Fri, 10 Jul 2009 10:48:11 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753838AbZGJOsJ (ORCPT ); Fri, 10 Jul 2009 10:48:09 -0400 Received: from mail-fx0-f218.google.com ([209.85.220.218]:34305 "EHLO mail-fx0-f218.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753546AbZGJOsI (ORCPT ); Fri, 10 Jul 2009 10:48:08 -0400 Received: by fxm18 with SMTP id 18so938436fxm.37 for ; Fri, 10 Jul 2009 07:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=y/pY3lDv4UpnmhmvMTamFO5yrZ5bvygpHZiMCnBFvGM=; b=Shtl9ZjaHEvP7RFifIRzZddroyaOHmHcJa03FOUifInbla3tLCs0sB3PjWtETlSZzL BhTzCxobBdlfIBYW6I8X0gguXm6dHbhHvCdLArq9MHDJJlnCKIyhxN5u0B22jdOsLvuo ERQOnsN1zb+egVQhQKxjuzspVG9ohXpQ09AqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=PJKm+1In+k+tbmCrlKQKaufeg0HTaGGPstz3sRGEmwRiwdzfrFjMxj0bVnbJUSDJMt Dz8hzLHYzDB/er0bo1A8b+jjo0gPvBVlTvI7Yc7X5wzLb6lDEx+DkDN1PZ9nnr58AvYf iYuDLQ9IeqJqyTdgUOCJLmsxz9yXTmIr9gHEc= Received: by 10.204.76.129 with SMTP id c1mr2002458bkk.9.1247237286403; Fri, 10 Jul 2009 07:48:06 -0700 (PDT) Received: from ami.dom.local ([79.162.159.1]) by mx.google.com with ESMTPS id 2sm2353913fks.33.2009.07.10.07.48.02 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Jul 2009 07:48:03 -0700 (PDT) Date: Fri, 10 Jul 2009 16:47:54 +0200 From: Jarek Poplawski To: =?iso-8859-2?Q?Pawe=B3?= Staszewski Cc: Eric Dumazet , Eric Dumazet , Linux Network Development list Subject: Re: weird problem Message-ID: <20090710144754.GA25385@ami.dom.local> References: <20090708223459.GB3666@ami.dom.local> <4A5679CC.800@itcare.pl> <4A568444.7010307@itcare.pl> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4A568444.7010307@itcare.pl> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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(-) --- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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)); } }