[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080520162646.GA14707@tpepper-t42p.dolavim.us>
Date: Tue, 20 May 2008 09:26:46 -0700
From: Tim Pepper <lnxninja@...ux.vnet.ibm.com>
To: Nadia Derbey <Nadia.Derbey@...l.net>
Cc: Tim Pepper <lnxninja@...ux.vnet.ibm.com>, manfred@...orfullife.com,
paulmck@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
efault@....de, akpm@...ux-foundation.org
Subject: Re: [PATCH 7/9] Make idr_remove rcu-safe
On Tue 20 May at 09:03:26 +0200 Nadia.Derbey@...l.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@...ux.vnet.ibm.com>
IBM Linux Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists