From: Andi Kleen <ak@suse.de>
To: netdev@oss.sgi.com
Cc: netfilter-devel@lists.netfilter.org
Subject: [PATCH] Reduce netfilter memory use on MP systems
Date: Fri, 4 Feb 2005 15:09:00 +0100 [thread overview]
Message-ID: <20050204140900.GD2518@wotan.suse.de> (raw)
On kernels compiled with a big NR_CPUS netfilter rules would
eat a lot of memory because all counters would be duplicated
for all NR_CPUs CPUs. With NR_CPUS=256 this would add up
to many MBs of memory.
This patch only allocates enough memory for the possible CPUs,
which is usually a much smaller number than NR_CPUS.
This allows loading of bigger rule sets on 64bit systems.
There is still a limit because someone else broke vmalloc to have a 64MB
limit on 64bit systems for single allocations, 129MB on 32bit.
It allocates an array of pages with kmalloc and kmalloc has a 128K limit.
To be fixed with a separate patch.
64bit systems were hurt worst because they tend to have big NR_CPUS
and the counters need more memory there, and the vmalloc limit is lower.
But it will raise the limits even on 32bit.
And in general it saves a lot of memory.
Tested only on a small dual CPU box.
Signed-off-by: Andi Kleen <ak@suse.de>
diff -u linux/net/ipv4/netfilter/ip_tables.c-o linux/net/ipv4/netfilter/ip_tables.c
--- linux/net/ipv4/netfilter/ip_tables.c-o 2005-02-04 09:40:12.000000000 +0100
+++ linux/net/ipv4/netfilter/ip_tables.c 2005-02-04 14:26:56.000000000 +0100
@@ -923,7 +923,7 @@
}
/* And one copy for every other CPU */
- for (i = 1; i < NR_CPUS; i++) {
+ for (i = 1; i < num_possible_cpus(); i++) {
memcpy(newinfo->entries + SMP_ALIGN(newinfo->size)*i,
newinfo->entries,
SMP_ALIGN(newinfo->size));
@@ -945,7 +945,7 @@
struct ipt_entry *table_base;
unsigned int i;
- for (i = 0; i < NR_CPUS; i++) {
+ for (i = 0; i < num_possible_cpus(); i++) {
table_base =
(void *)newinfo->entries
+ TABLE_OFFSET(newinfo, i);
@@ -992,7 +992,7 @@
unsigned int cpu;
unsigned int i;
- for (cpu = 0; cpu < NR_CPUS; cpu++) {
+ for (cpu = 0; cpu < num_possible_cpus(); cpu++) {
i = 0;
IPT_ENTRY_ITERATE(t->entries + TABLE_OFFSET(t, cpu),
t->size,
@@ -1130,7 +1130,7 @@
return -ENOMEM;
newinfo = vmalloc(sizeof(struct ipt_table_info)
- + SMP_ALIGN(tmp.size) * NR_CPUS);
+ + SMP_ALIGN(tmp.size) * num_possible_cpus());
if (!newinfo)
return -ENOMEM;
@@ -1460,7 +1460,7 @@
= { 0, 0, 0, { 0 }, { 0 }, { } };
newinfo = vmalloc(sizeof(struct ipt_table_info)
- + SMP_ALIGN(repl->size) * NR_CPUS);
+ + SMP_ALIGN(repl->size) * num_possible_cpus());
if (!newinfo)
return -ENOMEM;
next reply other threads:[~2005-02-04 14:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-04 14:09 Andi Kleen [this message]
2005-02-04 17:34 ` [PATCH] Reduce netfilter memory use on MP systems Martin Josefsson
2005-02-04 17:51 ` Andi Kleen
2005-02-04 18:13 ` Patrick McHardy
2005-02-07 18:31 ` Harald Welte
2005-02-07 19:10 ` Andi Kleen
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=20050204140900.GD2518@wotan.suse.de \
--to=ak@suse.de \
--cc=netdev@oss.sgi.com \
--cc=netfilter-devel@lists.netfilter.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).