netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH v2 -next 2/2] netfilter: store rules per NUMA node instead of per cpu
Date: Thu, 28 May 2015 23:52:23 +0200	[thread overview]
Message-ID: <20150528215223.GG23992@breakpoint.cc> (raw)
In-Reply-To: <1432849093.7456.32.camel@edumazet-glaptop2.roam.corp.google.com>

Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2015-05-28 at 22:51 +0200, Florian Westphal wrote:
> > We store rule blob per (possible) cpu.  Unfortunately this means we can
> > waste lot of memory on big smp machines. ipt_entry structure ('rule head')
> > is 112 byte, so e.g. with maxcpu=64 one single rule eats close to 8k RAM.
> > 
> > Since previous patch moved counters to separate percpu blob, it appears
> > there is nothing left in the rule blob that must be percpu.
> > 
> > Thus only duplicate the rule blob for each NUMA node.
> > 
> > On my test system (144 possible cpus, one numa node, 400k dummy rules) this
> > change saves close to 9 Gigabyte of RAM.
> > 
> > Reported-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> > Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > Signed-off-by: Florian Westphal <fw@strlen.de>
> > ---
> 
> Really if the program is now readonly, I would keep a single copy in
> memory.

Some matches (limit for instance) store kernel data ptr in their
matchinfo data (from checkentry hook, not per packet match function),
so its not 100% readonly.

> Are we copying kernel text to each NUMA node ? ;)

Beats me.  I was under impression that cpu accessing memory on other node
takes access penalty, thats why I changed it to per node allocation.

Is it insignificant in practice?

If so, I can respin it w/o the numa duplication; we can still add it
back later if needed.

  reply	other threads:[~2015-05-28 21:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-28 20:51 [PATCH v2 -next 1/2] netfilter: iptables: separate counters from iptables rules Florian Westphal
2015-05-28 20:51 ` [PATCH v2 -next 2/2] netfilter: store rules per NUMA node instead of per cpu Florian Westphal
2015-05-28 21:38   ` Eric Dumazet
2015-05-28 21:52     ` Florian Westphal [this message]
2015-05-28 22:04       ` Eric Dumazet
2015-05-29  9:41         ` Florian Westphal
2015-05-28 21:33 ` [PATCH v2 -next 1/2] netfilter: iptables: separate counters from iptables rules Eric Dumazet
2015-05-28 21:45   ` Florian Westphal
2015-05-28 21:54     ` Eric Dumazet
2015-05-29 10:05       ` Florian Westphal
2015-05-29 10:32         ` Eric Dumazet
2015-05-29 11:32 ` Patrick Schaaf
2015-06-05 12:28   ` Florian Westphal

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=20150528215223.GG23992@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=eric.dumazet@gmail.com \
    --cc=netfilter-devel@vger.kernel.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).