From patchwork Tue Jul 14 19:41:00 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jarek Poplawski X-Patchwork-Id: 29781 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 8D097B6F20 for ; Wed, 15 Jul 2009 05:41:40 +1000 (EST) Received: by ozlabs.org (Postfix) id 7AED3DDDA0; Wed, 15 Jul 2009 05:41:40 +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 D8514DDD1B for ; Wed, 15 Jul 2009 05:41:39 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756019AbZGNTle (ORCPT ); Tue, 14 Jul 2009 15:41:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755784AbZGNTle (ORCPT ); Tue, 14 Jul 2009 15:41:34 -0400 Received: from mail-fx0-f218.google.com ([209.85.220.218]:49103 "EHLO mail-fx0-f218.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755758AbZGNTld (ORCPT ); Tue, 14 Jul 2009 15:41:33 -0400 Received: by fxm18 with SMTP id 18so3030963fxm.37 for ; Tue, 14 Jul 2009 12:41:31 -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=+L7LI/mha4FUBons8aF2EG9zInehlK2UrE5MBN3/ZNo=; b=SdUMf5lsqFVyJUoRdxgn1as4eU0VleSBfGGdNtqGHjE6PnshWq+5mGbiU6UB+PNRQf 5rxYQpPQyEe7ktWOyIf8y1cNIV5XJycRFj+tc2SFvuZY7c67r90+M1C45LfTGmaR82kP Ghbp7z+JyMV459ZTRYVfxDiOa7oXsWTX0opk8= 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=hDzXiOEbGCQ9K8arGiE9PGejdzwqjrhgXYUVg96rH79ygGO5uYH7zGk2/2mxY3Vo+a uTa6Ay28pdM2un9/uNoxJIz+s3QpFliHA8rtgSSj7ml83XOSOgjrq+v7km+wq1tYn7WI MILzZhJ6u1840TNuwzb4IEtHoCX7nWGEEjhDc= Received: by 10.204.53.1 with SMTP id k1mr6713994bkg.50.1247600491025; Tue, 14 Jul 2009 12:41:31 -0700 (PDT) Received: from ami.dom.local ([79.162.141.243]) by mx.google.com with ESMTPS id e17sm10705088fke.48.2009.07.14.12.41.27 (version=SSLv3 cipher=RC4-MD5); Tue, 14 Jul 2009 12:41:29 -0700 (PDT) Date: Tue, 14 Jul 2009 21:41:00 +0200 From: Jarek Poplawski To: David Miller Cc: =?iso-8859-2?Q?Pawe=B3?= Staszewski , Linux Network Development list , Robert Olsson , "Jorge Boncompte [DTI2]" Subject: [PATCH net-next] Re: rib_trie / Fix inflate_threshold_root. Now=15 size=11 bits Message-ID: <20090714194100.GA7952@ami.dom.local> References: <4A4FF40B.5090003@itcare.pl> <20090705162003.GA19477@ami.dom.local> <20090705173208.GB19477@ami.dom.local> <20090705213232.GG8943@linux.vnet.ibm.com> <20090705222301.GA3203@ami.dom.local> <4A513D0D.5070204@itcare.pl> <20090706090207.GB3065@ami.dom.local> <4A53D28D.8060409@itcare.pl> <20090707235029.GA8207@ami.dom.local> <4A565449.4050403@itcare.pl> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4A565449.4050403@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 Thu, Jul 09, 2009 at 10:34:17PM +0200, Paweł Staszewski wrote: > Jarek Poplawski pisze: >> On Wed, Jul 08, 2009 at 12:56:13AM +0200, Paweł Staszewski wrote: ... >>> Also today i have many messages in dmesg like this: >>> Fix inflate_threshold_root. Now=25 size=11 bits >>> :) >>> >> >> This is something new and a bit surprising to me: the same threshold >> in previous tests didn't generate this? Do you mean more than: "Fix >> inflate_threshold_root. Now=15 size=11 bits" before? >> >> > Yes. Sorry for that - this info was not all the day but only 5 minutes > when i was making tests. > This info was reported only when all iBGP peers was down/up fast. > >>> And after tune : >>> /sys/module/fib_trie/parameters/inflate_threshold_root >>> no more info :) >>> >> >> With what value? >> >> > When i set 35 as inflate_threshold_root there was no info even if all > iBGP peers was down/up. So it looks like the patch tested earlier could be still useful; after changing the inflate_threshold_root it seems these warnings should be very rare but there is no reason to alarm users with something they can't fix optimally, anyway. Thanks, Jarek P. ---------------------> ipv4: Fix inflate_threshold_root automatically During large updates there could be triggered warnings like: "Fix inflate_threshold_root. Now=25 size=11 bits" if inflate() of the root node isn't finished in 10 loops. It should be much rarer now, after changing the threshold from 15 to 25, and a temporary problem, so this patch tries to handle it automatically using a fix variable to increase by one inflate threshold for next root resizes (up to the 35 limit, max fix = 10). The fix variable is decreased when root's inflate() finishes below 7 loops (even if some other, smaller table/ trie is updated -- for simplicity the fix variable is global for now). Reported-by: Pawel Staszewski Reported-by: Jorge Boncompte [DTI2] Tested-by: Pawel Staszewski Signed-off-by: Jarek Poplawski Signed-off-by: Robert Olsson --- -- 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 -Nurp a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c --- a/net/ipv4/fib_trie.c 2009-07-13 13:32:53.000000000 +0200 +++ b/net/ipv4/fib_trie.c 2009-07-13 15:16:18.000000000 +0200 @@ -327,6 +327,8 @@ static const int inflate_threshold = 50; static const int halve_threshold_root = 15; static const int inflate_threshold_root = 25; +static int inflate_threshold_root_fix; +#define INFLATE_FIX_MAX 10 /* a comment in resize() */ static void __alias_free_mem(struct rcu_head *head) { @@ -617,7 +619,8 @@ static struct node *resize(struct trie * /* Keep root node larger */ if (!tn->parent) - inflate_threshold_use = inflate_threshold_root; + inflate_threshold_use = inflate_threshold_root + + inflate_threshold_root_fix; else inflate_threshold_use = inflate_threshold; @@ -641,15 +644,27 @@ static struct node *resize(struct trie * } if (max_resize < 0) { - if (!tn->parent) - pr_warning("Fix inflate_threshold_root." - " Now=%d size=%d bits\n", - inflate_threshold_root, tn->bits); - else + if (!tn->parent) { + /* + * It was observed that during large updates even + * inflate_threshold_root = 35 might be needed to avoid + * this warning; but it should be temporary, so let's + * try to handle this automatically. + */ + if (inflate_threshold_root_fix < INFLATE_FIX_MAX) + inflate_threshold_root_fix++; + else + pr_warning("Fix inflate_threshold_root." + " Now=%d size=%d bits fix=%d\n", + inflate_threshold_root, tn->bits, + inflate_threshold_root_fix); + } else { pr_warning("Fix inflate_threshold." " Now=%d size=%d bits\n", inflate_threshold, tn->bits); - } + } + } else if (max_resize > 3 && !tn->parent && inflate_threshold_root_fix) + inflate_threshold_root_fix--; check_tnode(tn);