From: Steffen Klassert <steffen.klassert@secunet.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Wolfgang Walter <linux@stwm.de>,
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: Mon, 28 Oct 2013 12:30:39 +0100 [thread overview]
Message-ID: <20131028113039.GE31491@secunet.com> (raw)
In-Reply-To: <1382941051.13037.13.camel@edumazet-glaptop.roam.corp.google.com>
On Sun, Oct 27, 2013 at 11:17:31PM -0700, Eric Dumazet wrote:
> On Fri, 2013-10-25 at 11:20 +0200, Steffen Klassert wrote:
> > On Fri, Oct 25, 2013 at 01:50:28AM -0700, Eric Dumazet wrote:
> > >
> > > 32768 as the default seems fine to me
> > >
> > > 448 bytes per dst -> thats less than 30 Mbytes of memory if we hit 65536
> > > dst.
> > >
> >
> > Ok, I'll add the patch below to to the ipsec tree if everyone is fine
> > with that threshold.
> >
> > Subject: [PATCH RFC] xfrm: Increase the garbage collector threshold
> >
> > With the removal of the routing cache, we lost the
> > option to tweak the garbage collector threshold
> > along with the maximum routing cache size. So git
> > commit 703fb94ec ("xfrm: Fix the gc threshold value
> > for ipv4") moved back to a static threshold.
> >
> > It turned out that the current threshold before we
> > start garbage collecting is much to small for some
> > workloads, so increase it from 1024 to 32768. This
> > means that we start the garbage collector if we have
> > more than 32768 dst entries in the system and refuse
> > new allocations if we are above 65536.
> >
> > Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> > ---
>
> Sure please add :
>
> Reported-by: Wolfgang Walter <linux@stwm.de>
Done.
Now applied to the ipsec tree, thanks everyone!
next prev parent reply other threads:[~2013-10-28 11:30 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
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 [this message]
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=20131028113039.GE31491@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--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.