From: Marek Kierdelewicz <marek@piasta.pl>
To: Rick Jones <rick.jones2@hp.com>, netfilter@vger.kernel.org
Subject: Re: netfilter performance dependent on arch
Date: Tue, 7 Feb 2012 19:54:11 +0100 [thread overview]
Message-ID: <20120207195411.05a70f67@catus> (raw)
In-Reply-To: <4F316C1C.5020400@hp.com>
>> Can anyone point me to some performance comparison of netfilter on
>> i686 and x86_64? I have a few linux routers doing a lot of
>> firewalling and QoS. Currently those routers use i686 arch on 64-bit
>> hardware. Would I notice any performance gain after moving to 64-bit
>> kernel?
>Apart from the obvious "Try it on your workload and see." suggestion,
>you could I suppose make the assumption that a netfilter workload
>looks similar to one or more components of something like
Thanks for the response. Anyway moments ago I found answer to the first
question on vyatta forum here:
http://www.vyatta.org/forum/viewtopic.php?t=823&sid=3cec85f2cf7866ca26040ec491415ee1
shemminger "The researchers at Uppsla University who are measuring 10G
routing performance found that 64bit kernel is slower than 32bit kernel
for routing. Most likely the increased code size caused a larger number
of CPU cache misses. 64 bit would be an advantage if you are trying to
run lots of services."
DaveRoberts "This result is actually not too surprising. Networking code
is typically very cache sensitive. This gets worse with 64-bit. If
you're running code that uses data structures with lots of pointers
(which networking code often has) and you don't needed the expanded
address space, then you're wasting half your d-cache with 32 upper bits
of zeros. While the additional registers are a benefit, they aren't
enough to make up for the increased cache miss rate.
But as you say, without knowing the compiler, optimizer, and
instrumenting the heck out of the code with all the hardware analysis
counters, it's difficult to say what's really going on. All that is on
our list of things to do over time. The main takeaway is that it's
definitely not a slam dunk one way or another."
Best regards,
Marek Kierdelewicz
next prev parent reply other threads:[~2012-02-07 18:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-07 17:34 netfilter performance dependent on arch Marek Kierdelewicz
2012-02-07 18:23 ` Rick Jones
2012-02-07 18:54 ` Marek Kierdelewicz [this message]
2012-02-07 19:11 ` Stephen Hemminger
2012-02-07 19:48 ` Marek Kierdelewicz
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=20120207195411.05a70f67@catus \
--to=marek@piasta.pl \
--cc=netfilter@vger.kernel.org \
--cc=rick.jones2@hp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox