num_possible_cpus() usage in iptables
laforge at netfilter.org
Tue Oct 11 16:35:54 CEST 2005
On Mon, Oct 10, 2005 at 05:27:28PM -0700, David S. Miller wrote:
> From: Eric Dumazet <dada1 at cosmosbay.com>
> Date: Mon, 10 Oct 2005 08:23:27 +0200
> > My previous patch ([PATCH 3/3] netfilter : 3 patches to boost ip_tables
> > performance) addressed this problem.
> > http://marc.theaimsgroup.com/?l=linux-netdev&m=112733887410796&w=2
> Long term this is the kind of thing we should be doing.
> But for 2.6.14, I would like to suggest that we revert back
> to using NR_CPUS as that is the simplest fix for this bug.
> I even spent part of this afternoon investigating other kinds of
> fixes, and all of them have possible non-trivial regressions.
> Yes, using NR_CPUS wastes a lot of ram, but it fixes this
> bug in a straightforward and easy to verify fashion.
Mh. The problem is that I know a number of people who were running out
of RAM with moderate ruleset sizes (in the tens of thousands rules), and
the sole reason for switching from 2.4.x to 2.6.x was the NR_CPU to cpu
However, given that 2.6.14 seems close (and I cannot do testing on SMP
while on the road), it might be an interim solution.
OTOTH, how many users of systmes with discontiguous processor id space
are there vs. users with large rulesets on 2cpu machines that now have a
factor of 16 increased rule size (which can easily be a couple of 100mb
non-swappable kernel memory).
- Harald Welte <laforge at netfilter.org> http://netfilter.org/
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : /pipermail/netfilter-devel/attachments/20051011/8dfebe62/attachment-0001.pgp
More information about the netfilter-devel