[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0904101828490.4583@localhost.localdomain>
Date: Fri, 10 Apr 2009 18:39:18 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Miller <davem@...emloft.net>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Ingo Molnar <mingo@...e.hu>,
Lai Jiangshan <laijs@...fujitsu.com>
cc: shemminger@...tta.com, jeff.chua.linux@...il.com,
dada1@...mosbay.com, jengelh@...ozas.de, kaber@...sh.net,
r000n@...0n.net,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: iptables very slow after commit
784544739a25c30637397ace5489eeb6e15d7d49
On Fri, 10 Apr 2009, David Miller wrote:
>
> [ CC:'ing netfilter-devel and netdev... ]
I wonder if we should bring in the RCU people too, for them to tell you
that the networking people are beign silly, and should not synchronize
with the very heavy-handed
synchronize_net()
but instead of doing synchronization (which is probably why adding a few
hundred rules then takes several seconds - each synchronizes and that
takes a timer tick or so), add the rules to be free'd on some rcu-freeing
list for later freeing.
Or whatever. Paul? synchronize_net() just calls synchronize_rcu(), and
with that knowledge and a simple
git show 784544739a25c30637397ace5489eeb6e15d7d49
I bet you can already tell people how to fix their performance issue.
Linus
---
> > On Fri, 10 Apr 2009 17:15:52 +0800 (SGT)
> > Jeff Chua <jeff.chua.linux@...il.com> wrote:
> >>
> >> Adding 200 records in iptables took 6.0sec in 2.6.30-rc1 compared to
> >> 0.2sec in 2.6.29. I've bisected down this commit.
> >>
> >> There are a few patches on top of the original patch. When I reverted the
> >> original commit + changing rcu_read() to rcu_read_bh(), it speeds up the
> >> inserts back to .2sec again.
> >>
> >> I'm loading all the firewall rules during boot-up and this 6 secs slowness
> >> is really not very nice to wait for.
> >
> > The performance benefit during operation is more important. The load
> > time is fixable. The problem is probably generic to any set of rules,
> > but could you post some info about your configuration (like the rule
> > set), and the system configuration (# of cpu's, config etc).
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@...r.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists