From: "David S. Miller" <davem@davemloft.net>
To: vatsa@in.ibm.com
Cc: ak@suse.de, davem@redhat.com, netdev@oss.sgi.com,
linux-kernel@vger.kernel.org, dipankar@in.ibm.com,
paulmck@us.ibm.com
Subject: Re: [RFC] Use RCU for tcp_ehash lookup
Date: Wed, 1 Sep 2004 22:45:46 -0700 [thread overview]
Message-ID: <20040901224546.03765c8d.davem@davemloft.net> (raw)
In-Reply-To: <20040901113641.GA3918@in.ibm.com>
On Wed, 1 Sep 2004 17:06:41 +0530
Srivatsa Vaddagiri <vatsa@in.ibm.com> wrote:
> On Tue, Aug 31, 2004 at 03:54:20PM +0200, Andi Kleen wrote:
> > I bet also when you just do rdtsc timing for the TCP receive
> > path the cycle numbers will be way down (excluding the copy).
>
> I got cycle numbers for the lookup routine (with CONFIG_PREEMPT turned off).
> They were taken on a 900MHz 8way Intel P3 SMP box. The results are as below:
>
>
> -------------------------------------------------------------------------------
> | 2.6.8.1 | 2.6.8.1 + my patch
> -------------------------------------------------------------------------------
> Average cycles | |
> spent in | |
> __tcp_v4_lookup_established | 2970.65 | 668.227
> | (~3.3 micro-seconds) | (~0.74 microseconds)
> -------------------------------------------------------------------------------
>
> This repesents improvement by a factor of 77.5%!
And yet none of your benchmarks show noticable
improvements, which means that this micro-measurement
is totally unimportant in the grand scheme of things
as far as we know.
I'm not adding in a patch that merely provides some
micro-measurement improvement that someone can do a
shamans dance over. :) If we're going to add this
new level of complexity to the TCP code we need to
see some real usage performance improvement, not just
something that shows up when we put a microscope on
a single function.
next prev parent reply other threads:[~2004-09-02 5:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-31 12:59 [RFC] Use RCU for tcp_ehash lookup Srivatsa Vaddagiri
2004-08-31 13:04 ` Srivatsa Vaddagiri
2004-08-31 13:54 ` Andi Kleen
2004-09-01 11:36 ` Srivatsa Vaddagiri
2004-09-02 5:45 ` David S. Miller [this message]
2004-09-02 21:19 ` Andi Kleen
2004-09-02 5:43 ` David S. Miller
2004-09-02 5:41 ` David S. Miller
2004-09-02 14:04 ` Srivatsa Vaddagiri
2004-09-02 16:31 ` Paul E. McKenney
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=20040901224546.03765c8d.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=ak@suse.de \
--cc=davem@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=paulmck@us.ibm.com \
--cc=vatsa@in.ibm.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 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.