All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steffen Klassert <steffen.klassert@secunet.com>
To: Wolfgang Walter <linux@stwm.de>
Cc: David Miller <davem@davemloft.net>,
	hannes@stressinduktion.org, netdev@vger.kernel.org,
	klassert@mathematik.tu-chemnitz.de
Subject: Re: Big performance loss from 3.4.63 to 3.10.13 when routing ipv4
Date: Wed, 23 Oct 2013 14:04:34 +0200	[thread overview]
Message-ID: <20131023120434.GA22316@secunet.com> (raw)
In-Reply-To: <1748378.n7GIUzQXTX@h2o.as.studentenwerk.mhn.de>

On Wed, Oct 23, 2013 at 01:33:14PM +0200, Wolfgang Walter wrote:
> Am Mittwoch, 23. Oktober 2013, 10:12:55 schrieb Steffen Klassert:
> > On Tue, Oct 22, 2013 at 03:46:38PM -0400, David Miller wrote:
> > > 
> > > I think we should resolve this soon, even bumping it to 2048 or 4096
> > > and leaving it at that would be I think acceptable.
> > 
> > Yes, of course. Let's use 4096 as the default for ipv4 and ipv6.
> > I'll take care of it next week.
> > 
> 
> I don't know what this value actually means. But on 3.4.x it is much higher. 
> On a machine with 512MB ram it is 32768, on a machine with 1GB ram it is 
> 262144 and with 16GB ram it is 4194304.
> 

Before  we removed the routing cache, the gc threshold was scaled along
with the maximum routing cache size (ip_rt_max_size). With the routing
cache removal, we lost the possibility to scale with ip_rt_max_size
and we had to choose a static default. Maybe we can try to tweak the
gc threshold again with the available memory somehow later. But to fix
it now, we need to find a reasonable default value. Would a default of
4096 meet your requirements?

  parent reply	other threads:[~2013-10-23 12:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-01 16:39 Big performance loss from 3.4.63 to 3.10.13 when routing ipv4 Wolfgang Walter
2013-10-01 18:57 ` Brian Haley
2013-10-01 19:44   ` Wolfgang Walter
2013-10-01 22:20 ` Hannes Frederic Sowa
2013-10-22 19:07   ` Wolfgang Walter
2013-10-22 19:46     ` David Miller
2013-10-23  8:12       ` Steffen Klassert
2013-10-23 11:33         ` Wolfgang Walter
2013-10-23 12:00           ` Eric Dumazet
2013-10-23 12:26             ` Steffen Klassert
2013-10-23 15:57             ` Wolfgang Walter
2013-10-23 12:04           ` Steffen Klassert [this message]
2013-10-23 16:05             ` Wolfgang Walter
     [not found] ` <3169911.kTmZ0BZVVr@h2o.as.studentenwerk.mhn.de>
     [not found]   ` <1382547992.7572.31.camel@edumazet-glaptop.roam.corp.google.com>
2013-10-23 22:52     ` Wolfgang Walter
2013-10-25  8:01       ` Steffen Klassert
2013-10-25  8:50         ` Eric Dumazet
2013-10-25  9:20           ` Steffen Klassert
2013-10-28  4:43             ` David Miller
2013-10-28  6:17             ` Eric Dumazet
2013-10-28 11:30               ` Steffen Klassert
2013-10-25  9:33         ` Wolfgang Walter
2013-10-24 11:07     ` Wolfgang Walter

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=20131023120434.GA22316@secunet.com \
    --to=steffen.klassert@secunet.com \
    --cc=davem@davemloft.net \
    --cc=hannes@stressinduktion.org \
    --cc=klassert@mathematik.tu-chemnitz.de \
    --cc=linux@stwm.de \
    --cc=netdev@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 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.