From: Cyrill Gorcunov <gorcunov@gmail.com>
To: David Miller <davem@davemloft.net>,
alexei.starovoitov@gmail.com, eric.dumazet@gmail.com
Cc: netdev@vger.kernel.org, solar@openwall.com, vvs@virtuozzo.com,
avagin@virtuozzo.com, xemul@virtuozzo.com,
vdavydov@virtuozzo.com, khorenko@virtuozzo.com
Subject: Re: [RFC] net: ipv4 -- Introduce ifa limit per net
Date: Wed, 9 Mar 2016 22:55:28 +0300 [thread overview]
Message-ID: <20160309195528.GN2207@uranus.lan> (raw)
In-Reply-To: <20160309175307.GM2207@uranus.lan>
On Wed, Mar 09, 2016 at 08:53:07PM +0300, Cyrill Gorcunov wrote:
> On Wed, Mar 09, 2016 at 12:24:00PM -0500, David Miller wrote:
> ...
> > We asked you for numbers without a lot of features enabled, it'll
> > help us diagnose which subsystem still causes a lot of overhead
> > much more clearly.
> >
> > So please do so.
>
> Sure. Gimme some time and I'll back with numbers.
OK, here are the results (with preempt-debug/trace disabled,
on the kernel with David's two patches).
---
No conntrack
------------
[root@s125 ~]# ./exploit.sh
START 4 addresses STOP 1457549979 1457549980 -> 1
START 2704 addresses STOP 1457549983 1457549984 -> 1
START 10404 addresses STOP 1457549996 1457549997 -> 1
START 23104 addresses STOP 1457550029 1457550030 -> 1
START 40804 addresses STOP 1457550103 1457550104 -> 1
START 63504 addresses STOP 1457550267 1457550268 -> 1
all works quite fast, takes 1 second.
With conntrack
--------------
1) In a middle of "release -> create new addresses" transition
27.53% [kernel] [k] __local_bh_enable_ip
26.29% [kernel] [k] _raw_spin_lock
6.00% [kernel] [k] nf_ct_iterate_cleanup
3.95% [kernel] [k] nf_conntrack_lock
2.94% [kernel] [k] _raw_spin_unlock
1.91% [kernel] [k] _cond_resched
1.78% [kernel] [k] check_lifetime
1.25% [kernel] [k] __inet_insert_ifa
1.19% [kernel] [k] inet_rtm_newaddr
2) Last one with 63K of addresses releasing
36.36% [kernel] [k] __local_bh_enable_ip
34.75% [kernel] [k] _raw_spin_lock
7.93% [kernel] [k] nf_ct_iterate_cleanup
5.11% [kernel] [k] nf_conntrack_lock
3.71% [kernel] [k] _raw_spin_unlock
2.51% [kernel] [k] _cond_resched
0.89% [kernel] [k] task_tick_fair
0.77% [kernel] [k] native_write_msr_safe
0.58% [kernel] [k] hrtimer_active
0.52% [kernel] [k] rcu_check_callbacks
[root@s125 ~]# ./exploit.sh
START 4 addresses STOP 1457552395 1457552397 -> 2
START 2704 addresses STOP 1457552399 1457552403 -> 4
START 10404 addresses STOP 1457552415 1457552429 -> 14
START 23104 addresses STOP 1457552461 1457552492 -> 31
START 40804 addresses STOP 1457552566 1457552620 -> 54
START 63504 addresses STOP 1457552785 1457552870 -> 85
at the final stage it took 85 seconds to become alive. All
eaten inside nf_ct_iterate_cleanup (actually inside
get_next_corpse). IIRC there were some feature of perf
which could annotate the instructions, no? Have to refresh
memory on how to use perf record and such...
next prev parent reply other threads:[~2016-03-09 19:55 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-04 21:39 [RFC] net: ipv4 -- Introduce ifa limit per net Cyrill Gorcunov
2016-03-04 22:50 ` David Miller
2016-03-05 0:08 ` Eric Dumazet
2016-03-05 4:11 ` David Miller
2016-03-05 7:18 ` Cyrill Gorcunov
2016-03-05 15:57 ` Cyrill Gorcunov
2016-03-05 16:33 ` David Miller
2016-03-05 17:00 ` Cyrill Gorcunov
2016-03-05 18:44 ` Cyrill Gorcunov
2016-03-06 10:09 ` Cyrill Gorcunov
2016-03-06 16:23 ` Eric Dumazet
2016-03-06 17:06 ` Cyrill Gorcunov
2016-03-09 16:39 ` Cyrill Gorcunov
2016-03-09 16:51 ` Cyrill Gorcunov
2016-03-09 16:58 ` Alexei Starovoitov
2016-03-09 17:09 ` Cyrill Gorcunov
2016-03-09 17:24 ` David Miller
2016-03-09 17:53 ` Cyrill Gorcunov
2016-03-09 19:55 ` Cyrill Gorcunov [this message]
2016-03-09 20:27 ` David Miller
2016-03-09 20:41 ` Cyrill Gorcunov
2016-03-09 20:47 ` David Miller
2016-03-09 20:57 ` Cyrill Gorcunov
2016-03-09 21:10 ` David Miller
2016-03-09 21:16 ` Cyrill Gorcunov
2016-03-10 10:20 ` Cyrill Gorcunov
2016-03-10 11:03 ` Cyrill Gorcunov
2016-03-10 15:09 ` Cyrill Gorcunov
2016-03-10 18:01 ` David Miller
2016-03-10 18:48 ` Cyrill Gorcunov
2016-03-10 19:02 ` Cong Wang
2016-03-10 19:55 ` David Miller
2016-03-10 20:01 ` Cyrill Gorcunov
2016-03-10 20:03 ` David Miller
2016-03-10 20:13 ` Cyrill Gorcunov
2016-03-10 20:19 ` Cyrill Gorcunov
2016-03-10 21:05 ` David Miller
2016-03-10 21:19 ` Cyrill Gorcunov
2016-03-10 21:59 ` Cyrill Gorcunov
2016-03-10 22:36 ` David Miller
2016-03-10 22:40 ` Cyrill Gorcunov
2016-03-11 20:40 ` David Miller
2016-03-11 20:58 ` Florian Westphal
2016-03-11 21:00 ` Cyrill Gorcunov
2016-03-11 21:22 ` Cyrill Gorcunov
2016-03-11 21:59 ` Cyrill Gorcunov
2016-03-14 3:29 ` David Miller
2016-03-10 21:09 ` Cong Wang
2016-03-09 17:19 ` David Miller
2016-03-05 6:58 ` Cyrill Gorcunov
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=20160309195528.GN2207@uranus.lan \
--to=gorcunov@gmail.com \
--cc=alexei.starovoitov@gmail.com \
--cc=avagin@virtuozzo.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=khorenko@virtuozzo.com \
--cc=netdev@vger.kernel.org \
--cc=solar@openwall.com \
--cc=vdavydov@virtuozzo.com \
--cc=vvs@virtuozzo.com \
--cc=xemul@virtuozzo.com \
/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.