netdev - Re: Big performance loss from 3.4.63 to 3.10.13 when routing ipv4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131025080158.GC31491@secunet.com>
Date:	Fri, 25 Oct 2013 10:01:58 +0200
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Wolfgang Walter <linux@...m.de>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	David Miller <davem@...emloft.net>, hannes@...essinduktion.org,
	netdev@...r.kernel.org, klassert@...hematik.tu-chemnitz.de
Subject: Re: Big performance loss from 3.4.63 to 3.10.13 when routing ipv4

On Thu, Oct 24, 2013 at 12:52:58AM +0200, Wolfgang Walter wrote:
> On Wednesday 23 October 2013 10:06:32 Eric Dumazet wrote:
> > On Wed, 2013-10-23 at 18:59 +0200, Wolfgang Walter wrote:
> > > Ah, ok. I use SLUB, but SLABINFO=y.
> > > 
> > > Without much traffic it is:
> > > 
> > > # grep dst /proc/slabinfo
> > > xfrm_dst_cache      4435   4608    448   36    4 : tunables    0    0    0
> > > : slabdata    128    128      0
> > > 
> > > on the big one.
> > > 
> > > I can recompile the kernels with SLAB instead of SLUB if SLAB gives more
> > > usefull infos.
> > Not needed, because it seems we do not merge this SLUB cache with
> > another one.
> 
> Ok. I can't see xfrm_dst_cache on 32bit-systems, though.
> 
> > 
> > So please post this information, because I believe the default should be
> > 65536, not 1024 or 4096
> > 
> 
> Indeed I already saw higher values, at the moment I see:
> 
> # while true; do grep dst /proc/slabinfo ; sleep 1; done
> xfrm_dst_cache     12636  12636    448   36    4 : tunables    0    0    0 : slabdata    351    351      0

We currently start the garbage collector if we have more than gc_thresh
(1024) dst entries allocated and refuse new allocations at 2 * gc_thresh.

So maybe we should set gc_thresh to 32768. Than we can have 65536 dst
entries in the system (cache + packets in flight) before we refuse
new allocations. In paticular we can still cache another 32768 dst
entries after the garbage collector was started. It looks like you
had never more than 15000 dst entries cached, so a default of 32768
looks reasonable and should also keep smaller embedded routers happy.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html