All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rick Jones <rick.jones2@hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [git pull] ia64 changes
Date: Tue, 29 Sep 2009 00:03:36 +0000	[thread overview]
Message-ID: <4AC14ED8.4030407@hp.com> (raw)
In-Reply-To: <1FE6DD409037234FAB833C420AA843EC0122AEB1@orsmsx424.amr.corp.intel.com>

Luck, Tony wrote:
> Here are the source and disassembled binary for the lock/unlock
> routines modified as suggested by Linus to fit the lock word
> back into 32-bits.
> 
> Performance for lock/unlock time in the uncontended in-cache case
> is a little worse (another 8% on top of the 8% I'd already given
> up compared to the original "xchg" version). 

Youch, that is 17% if I've done the math correctly.  This is to deal with 
contended locks more "fairly" correct?

> I haven't tried a macro-level benchmark yet to see whether this makes it
> noticeable.

Not exactly macro with a big M, but something like netperf aggregate TCP_RR 
would probably do a fair bit of lock/unlock exercise.

Taking ftp://ftp.netperf.org/netperf/netperf-2.4.5.tar.bz2

then

tar xjf netperf-2.4.5-tar.bz2
cd netperf-2.4.5
./configure --enable-burst --prefix=<your choice>
make install
netserver

and then it should be possible to see what the max single-connection, 
single-byte, aggregate TCP_RR perf is with something like:

for b in 0 1 4 16 64 256
do
netperf -t TCP_RR -i 30,3 -P 0 -B "burst $b" -- -r 1 -D -b $b
done

where the values for b can be as you choose - 0 means no additional transaction 
in flight at one time, so just the one synchronous transaction.  The -i 30,3 
means repeat each data point at least 3 times but no more than 30 to get the 
default confidence interval of 99% confident the result is within +/- 2.5% (you 
can make that stricter with -I 99,N where N is 2x the +/- you want).  The -P 0 
tells netperf to omit the test banner (makes the output more readable).  The -B 
is a user supplied tag emitted with the result.  The options after the "--" are 
test-specific - in this case -r 1 means request and response size of 1 byte, -D 
means set TCP_NODELAY and the -b $b means add an additional $b transactions in 
flight at one time on the connection.

You may need/want to mess with a global (before the "--") -T option to bind 
netperf/netserver to specific cores:

-T N   # both netperf and netserver to core N on their respective systems
-T N,  # just netperf to core N, netserver floats
-T  ,M # netperf floats, netserver to core M
-T N,M # netperf to N, netserver to M

Once you have come-up with the peak setting for the -b option, you can then do a 
variation on the theme to run multiple, concurrent netperfs:

for i in 1 2 ...
do
netperf -t TCP_RR -i 30 -P 0 -- -r 1 -D -b <burst> &
done

where now each backgrounded netperf will run 30 iterations no matter what - you 
may still want to mess about with the scripting and bind netperf/netserver as 
you wish, or not.  I find the binding helps make things more repeatable.

rick jones

  parent reply	other threads:[~2009-09-29  0:03 UTC|newest]

Thread overview: 110+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-18 16:34 [git pull] ia64 changes Luck, Tony
2008-04-22 23:36 ` Luck, Tony
2008-04-24 23:51 ` Luck, Tony
2008-04-24 23:51   ` Luck, Tony
2008-04-25  0:16   ` Adrian Bunk
2008-04-25  0:16     ` Adrian Bunk
2008-04-25  0:25     ` Luck, Tony
2008-04-25  0:25       ` Luck, Tony
2008-04-25  0:41       ` [2.6 patch] ia64: let NUMA select SMP Adrian Bunk
2008-04-25  0:41         ` Adrian Bunk
2008-04-25  1:01         ` Luck, Tony
2008-04-25  1:01           ` Luck, Tony
2008-04-25 12:50         ` Mike Travis
2008-04-25 12:50           ` Mike Travis
2008-04-29 23:36 ` [git pull] ia64 changes Luck, Tony
2008-05-01 22:57 ` Luck, Tony
2008-05-15 20:46 ` Luck, Tony
2008-05-28 19:52 ` Luck, Tony
2008-06-16 17:28 ` Luck, Tony
2008-06-24 21:49 ` Luck, Tony
2008-06-30 23:52 ` Luck, Tony
2008-07-17 20:31 ` Luck, Tony
2008-07-25 20:30 ` Luck, Tony
2008-08-06 18:32 ` Luck, Tony
2008-08-12 21:55 ` Luck, Tony
2008-08-18 23:46 ` Luck, Tony
2008-08-26 16:59 ` Luck, Tony
2008-09-10 21:17 ` Luck, Tony
2008-09-23 16:59 ` Luck, Tony
2008-09-30 16:18 ` Luck, Tony
2008-10-21 18:01 ` Luck, Tony
2008-11-05  0:43 ` Luck, Tony
2008-11-07 18:00 ` Luck, Tony
2008-11-20 22:47 ` Luck, Tony
2008-12-09 22:28 ` Luck, Tony
2009-01-15 19:45 ` Luck, Tony
2009-02-19 21:02 ` Luck, Tony
2009-02-25 22:44 ` Luck, Tony
2009-03-06 22:17 ` Luck, Tony
2009-03-27 17:46 ` Luck, Tony
2009-04-01 20:20 ` Luck, Tony
2009-04-08 22:33 ` Luck, Tony
2009-04-20 17:32 ` Luck, Tony
2009-05-05 22:42 ` Luck, Tony
2009-06-15 17:20 ` Luck, Tony
2009-07-17 18:11 ` Fenghua Yu
2009-08-11 23:40 ` Fenghua Yu
2009-09-02 17:28 ` Luck, Tony
2009-09-17 17:11 ` Luck, Tony
2009-09-26 19:57 ` Luck, Tony
2009-09-26 20:39 ` Linus Torvalds
2009-09-26 23:16 ` Matthew Wilcox
2009-09-27  0:00 ` Linus Torvalds
2009-09-27  0:08 ` Linus Torvalds
2009-09-27  4:54 ` Luck, Tony
2009-09-27  5:18 ` Linus Torvalds
2009-09-27  5:20 ` Luck, Tony
2009-09-28 19:02 ` Boehm, Hans
2009-09-28 22:35 ` Luck, Tony
2009-09-28 22:54 ` Linus Torvalds
2009-09-28 23:01 ` Linus Torvalds
2009-09-28 23:01 ` Luck, Tony
2009-09-29  0:03 ` Rick Jones [this message]
2009-09-29  0:14 ` Linus Torvalds
2009-09-29 17:53 ` Luck, Tony
2009-09-29 18:07 ` Linus Torvalds
2009-09-30  0:54 ` Robin Holt
2009-09-30  1:24 ` Linus Torvalds
2009-09-30  1:30 ` Linus Torvalds
2009-09-30  2:46 ` Robin Holt
2009-09-30  2:56 ` Linus Torvalds
2009-09-30 18:00 ` Rick Jones
2009-11-02 18:07 ` Luck, Tony
2009-12-15 22:33 ` Luck, Tony
2010-01-08 17:20 ` Luck, Tony
2010-01-08 17:35 ` Linus Torvalds
2010-01-08 17:49 ` Luck, Tony
2010-01-08 19:24 ` Luck, Tony
2010-02-16 19:43 ` Luck, Tony
2010-02-24 17:32 ` Luck, Tony
2010-03-01 18:11 ` Luck, Tony
2010-05-18 17:11 ` Luck, Tony
2010-05-18 20:43 ` Robin Holt
2010-05-18 22:04 ` Luck, Tony
2010-07-01 15:22 ` Luck, Tony
2010-08-04 16:09 ` Luck, Tony
2010-08-14  4:04 ` Luck, Tony
2010-08-18 20:06 ` Luck, Tony
2010-09-13 18:33 ` Luck, Tony
2010-09-14  6:06 ` Petr Tesarik
2010-09-14  7:02 ` Petr Tesarik
2010-09-14 17:37 ` Luck, Tony
2010-09-14 20:38 ` Petr Tesarik
2010-09-14 20:57 ` Tony Luck
2010-09-16 15:57 ` Luck, Tony
2010-10-21 16:00 ` Luck, Tony
2010-10-21 21:33 ` Linus Torvalds
2011-01-10 18:01 ` Luck, Tony
2011-01-13 18:08 ` Luck, Tony
2011-01-13 23:10 ` Luck, Tony
2011-01-14 19:33 ` Luck, Tony
2011-03-24 16:29 ` Luck, Tony
2011-03-24 16:29   ` Luck, Tony
2011-03-30 19:09 ` Luck, Tony
2011-05-31 20:20 ` Luck, Tony
2011-08-01 16:57 ` Luck, Tony
2011-11-02 21:06 ` Luck, Tony
2012-01-05 17:42 ` Luck, Tony
2012-03-23 17:23 ` [GIT PULL] " Luck, Tony
  -- strict thread matches above, loose matches on Subject: below --
2010-07-21 16:40 [git pull] " Luck, Tony

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=4AC14ED8.4030407@hp.com \
    --to=rick.jones2@hp.com \
    --cc=linux-ia64@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 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.