From: Andi Kleen <ak@suse.de>
To: Harald Welte <laforge@netfilter.org>
Cc: netdev@vger.kernel.org, netfilter-devel@lists.netfilter.org,
linux-kernel@vger.kernel.org,
Henrik Nordstrom <hno@marasystems.com>
Subject: Re: [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance
Date: Wed, 28 Sep 2005 10:37:02 +0200 [thread overview]
Message-ID: <200509281037.03185.ak@suse.de> (raw)
In-Reply-To: <20050928083240.GP4168@sunbeam.de.gnumonks.org>
On Wednesday 28 September 2005 10:32, Harald Welte wrote:
> I totally agree, that from a current perspective, I think the concept of
> just loading a module (that has usage count 0) having severe impact on
> system performance is just wrong. But then, users are used to the
> current behaviour for almost five years now.
That doesn't mean it cannot be improved - and I think it should.
In a sense it's even getting worse: For example us losing the CONFIG
option to disable local conntrack (Patrick has disabled it some time ago
without even a comment why he did it) has a really bad impact in some cases.
> Therefore: Let's do this right next time, but live with that fact for
> now.
Even with a "quite straight-forward" (quoting you) fix?
> Just imagine all those poor sysadmins who know nothing about current
> kernel development, and who upgrade their kernel because their
> distributor provides a new one - suddenly their accounting (which might
> be relevant for their business) doesn't work anymore :(
Accounting with per CPU counters can be done fully lockless.
-Andi
WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <ak@suse.de>
To: Harald Welte <laforge@netfilter.org>
Cc: Henrik Nordstrom <hno@marasystems.com>,
netdev@vger.kernel.org, netfilter-devel@lists.netfilter.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance
Date: Wed, 28 Sep 2005 10:37:02 +0200 [thread overview]
Message-ID: <200509281037.03185.ak@suse.de> (raw)
In-Reply-To: <20050928083240.GP4168@sunbeam.de.gnumonks.org>
On Wednesday 28 September 2005 10:32, Harald Welte wrote:
> I totally agree, that from a current perspective, I think the concept of
> just loading a module (that has usage count 0) having severe impact on
> system performance is just wrong. But then, users are used to the
> current behaviour for almost five years now.
That doesn't mean it cannot be improved - and I think it should.
In a sense it's even getting worse: For example us losing the CONFIG
option to disable local conntrack (Patrick has disabled it some time ago
without even a comment why he did it) has a really bad impact in some cases.
> Therefore: Let's do this right next time, but live with that fact for
> now.
Even with a "quite straight-forward" (quoting you) fix?
> Just imagine all those poor sysadmins who know nothing about current
> kernel development, and who upgrade their kernel because their
> distributor provides a new one - suddenly their accounting (which might
> be relevant for their business) doesn't work anymore :(
Accounting with per CPU counters can be done fully lockless.
-Andi
next prev parent reply other threads:[~2005-09-28 8:37 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-19 17:09 [PATCH, netfilter] NUMA aware ipv4/netfilter/ip_tables.c Eric dumazet
2005-09-19 17:20 ` Eric Dumazet
2005-09-19 17:48 ` Andi Kleen
2005-09-19 19:09 ` Eric Dumazet
2005-09-20 9:47 ` Eric Dumazet
2005-09-20 16:30 ` Andi Kleen
2005-09-20 17:02 ` Eric Dumazet
2005-09-20 21:45 ` [PATCH] Adds sys_set_mempolicy() in include/linux/syscalls.h , " Eric Dumazet
2005-09-20 21:45 ` Eric Dumazet
2005-09-20 21:46 ` [PATCH] Adds sys_set_mempolicy() in include/linux/syscalls.h Eric Dumazet
2005-09-21 21:24 ` [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance Eric Dumazet
2005-09-21 22:43 ` Christoph Lameter
2005-09-22 0:34 ` David S. Miller
2005-09-22 0:34 ` David S. Miller
2005-09-22 1:44 ` Christoph Lameter
2005-09-22 12:11 ` Eric Dumazet
2005-09-22 12:11 ` Eric Dumazet
2005-09-22 12:49 ` Christoph Hellwig
2005-09-22 12:54 ` Andi Kleen
2005-09-22 12:58 ` Christoph Hellwig
2005-09-22 13:05 ` Andi Kleen
2005-09-22 15:37 ` Christoph Lameter
2005-09-22 15:50 ` Eric Dumazet
2005-09-22 15:50 ` Eric Dumazet
2005-09-22 15:55 ` Christoph Lameter
2005-09-23 17:11 ` Harald Welte
2005-09-23 17:44 ` Christoph Lameter
2005-09-23 18:04 ` Dave Hansen
2005-09-26 17:58 ` vmalloc_node Christoph Lameter
2005-09-26 18:10 ` vmalloc_node Dave Hansen
2005-09-23 17:47 ` [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance Eric Dumazet
2005-09-23 18:00 ` Kyle Moffett
2005-09-22 4:18 ` James Morris
2005-09-22 4:18 ` James Morris
2005-09-22 5:07 ` Eric Dumazet
2005-09-22 13:03 ` Andi Kleen
2005-09-22 13:30 ` Eric Dumazet
2005-09-23 17:09 ` Harald Welte
2005-09-27 16:23 ` Andi Kleen
2005-09-28 0:25 ` Henrik Nordstrom
2005-09-28 8:32 ` Harald Welte
2005-09-28 8:32 ` Harald Welte
2005-09-28 8:37 ` Andi Kleen [this message]
2005-09-28 8:37 ` Andi Kleen
2005-10-04 17:01 ` Patrick McHardy
2005-10-05 16:53 ` Andi Kleen
2005-10-07 2:38 ` Harald Welte
2005-10-06 17:59 ` Andi Kleen
2005-10-07 17:08 ` Patrick McHardy
2005-10-07 17:21 ` Andi Kleen
2005-10-07 17:50 ` Patrick McHardy
2005-09-28 10:34 ` Henrik Nordstrom
2005-09-28 10:34 ` Henrik Nordstrom
2005-11-25 11:23 ` [PATCH] netfilter : zap get_cpu()/put_cpu() calls from ip_tables Eric Dumazet
2005-11-25 11:28 ` [PATCH (resent with the attachment !)] " Eric Dumazet
2005-11-25 18:20 ` Patrick McHardy
2005-09-21 21:29 ` [PATCH 1/3] netfilter : 3 patches to boost ip_tables performance Eric Dumazet
2005-09-22 12:57 ` Harald Welte
2005-09-22 12:57 ` Harald Welte
2005-09-22 13:17 ` Eric Dumazet
2005-09-22 13:17 ` Eric Dumazet
2005-09-21 21:32 ` [PATCH 2/3] " Eric Dumazet
2005-09-22 12:48 ` Harald Welte
2005-09-22 12:48 ` Harald Welte
2005-09-22 13:05 ` Eric Dumazet
2005-09-23 4:02 ` Willy Tarreau
2005-09-23 5:14 ` Eric Dumazet
2005-09-23 11:33 ` Willy Tarreau
2005-09-23 14:00 ` Tim Mattox
2005-09-21 21:37 ` [PATCH 3/3] " Eric Dumazet
2005-09-22 12:50 ` Harald Welte
2005-09-22 12:50 ` Harald Welte
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=200509281037.03185.ak@suse.de \
--to=ak@suse.de \
--cc=hno@marasystems.com \
--cc=laforge@netfilter.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.