linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tim Pepper <lnxninja@linux.vnet.ibm.com>
To: Nadia Derbey <Nadia.Derbey@bull.net>
Cc: Tim Pepper <lnxninja@linux.vnet.ibm.com>,
	manfred@colorfullife.com, paulmck@linux.vnet.ibm.com,
	linux-kernel@vger.kernel.org, efault@gmx.de,
	akpm@linux-foundation.org
Subject: Re: [PATCH 7/9] Make idr_remove rcu-safe
Date: Tue, 20 May 2008 09:26:46 -0700	[thread overview]
Message-ID: <20080520162646.GA14707@tpepper-t42p.dolavim.us> (raw)
In-Reply-To: <483277BE.6060207@bull.net>

On Tue 20 May at 09:03:26 +0200 Nadia.Derbey@bull.net said:
>> 60	 91581.07	158207.08	 797796.94	2970977.25
>> 61	 89209.40	160529.38	1202135.38	2538114.50
>> 62	 89008.45	167843.78	1305666.75	2274845.00
>> 63	 97753.17	177470.12	 733957.31	 363952.62
>> 64	102556.05	175923.56	1356988.88	 199527.83
>>
> Actually there are 2 numbers that bother me: those for the contended loops 
> on the patched kernel (63 and 64 threads) - the last 2 numbers in the 
> rightmost column.

> Did you have the opportunity to run that same test for 128 threads: this is 
> just for me to check whether 64 is not the #of threads we are starting to 
> slow down from.

I don't have results from a run handy with over 64 threads with the
patched kernel for the contended case.  But from what I've seen, the
closer the number of test threads is to the number of actual cores,
not SMT threads, the more noisy the test gets.  I think this is
reasonable/expected and that there's nothing magic about 63 or 64
threads.

We've been having network issues in the lab where this big box is.
If/when I can get access long enough, I'll do a series of runs including
past 64threads give averaged results and deviations.

-- 
Tim Pepper  <lnxninja@linux.vnet.ibm.com>
IBM Linux Technology Center

  reply	other threads:[~2008-05-20 16:27 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-07 11:35 [PATCH 0/9] Scalability requirements for sysv ipc - v3 Nadia.Derbey
2008-05-07 11:35 ` [PATCH 1/9] Change the idr structure Nadia.Derbey
2008-05-08 17:12   ` Rik van Riel
2008-05-30  8:22   ` Paul E. McKenney
2008-05-07 11:35 ` [PATCH 2/9] Rename some of the idr APIs internal routines Nadia.Derbey
2008-05-08 17:15   ` Rik van Riel
2008-05-30  8:23   ` Paul E. McKenney
2008-05-07 11:35 ` [PATCH 3/9] Fix a printk call Nadia.Derbey
2008-05-08 17:43   ` Rik van Riel
2008-05-30  8:23   ` Paul E. McKenney
2008-05-07 11:35 ` [PATCH 4/9] Error checking factorization Nadia.Derbey
2008-05-08 17:45   ` Rik van Riel
2008-05-07 11:35 ` [PATCH 5/9] Make idr_get_new* rcu-safe Nadia.Derbey
2008-05-08 17:55   ` Rik van Riel
2008-05-30  8:23   ` Paul E. McKenney
2008-05-07 11:35 ` [PATCH 6/9] Make idr_find rcu-safe Nadia.Derbey
2008-05-08 17:58   ` Rik van Riel
2008-05-30  8:24   ` Paul E. McKenney
2008-05-07 11:36 ` [PATCH 7/9] Make idr_remove rcu-safe Nadia.Derbey
2008-05-08 18:02   ` Rik van Riel
2008-05-14 19:59   ` Tim Pepper
2008-05-15  7:40     ` Nadia Derbey
2008-05-20  5:29       ` Tim Pepper
2008-05-20  5:35         ` Tim Pepper
2008-05-20  7:03         ` Nadia Derbey
2008-05-20 16:26           ` Tim Pepper [this message]
2008-05-30  8:24   ` Paul E. McKenney
2008-05-07 11:36 ` [PATCH 8/9] Call idr_find() without locking in ipc_lock() Nadia.Derbey
2008-05-08 18:11   ` Rik van Riel
2008-05-30  8:27   ` Paul E. McKenney
2008-05-07 11:36 ` [PATCH 9/9] Get rid of ipc_lock_down() Nadia.Derbey
2008-05-08 18:13   ` Rik van Riel
2008-05-30  8:29   ` Paul E. McKenney
2008-05-07 11:41 ` [PATCH 0/9] Scalability requirements for sysv ipc - v3 Nadia Derbey
2008-05-07 13:19 ` KOSAKI Motohiro
2008-05-13 14:10   ` Nadia Derbey
2008-05-14  4:22     ` KOSAKI Motohiro
2008-05-30  8:22 ` Paul E. McKenney
2008-06-02  5:53   ` Nadia Derbey

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=20080520162646.GA14707@tpepper-t42p.dolavim.us \
    --to=lnxninja@linux.vnet.ibm.com \
    --cc=Nadia.Derbey@bull.net \
    --cc=akpm@linux-foundation.org \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=paulmck@linux.vnet.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 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).