Re: [patch] increase spinlock-debug looping timeouts (write_lockand NMI)

[Nick Piggin]

Ingo Molnar wrote:
> curious, do you have any (relatively-) simple to run testcase that 
> clearly shows the "scalability issues" you mention above, when going 
> from rwlocks to spinlocks? I'd like to give it a try on an 8-way box.

Arjan van de Ven wrote:
> I'm curious what scalability advantage you see for rw spinlocks vs real
> spinlocks ... since for any kind of moderate hold time the opposite is
> expected ;)

It actually surprised me too, but Peter Chubb (who IIRC provided the
motivation to merge the patch) showed some fairly significant improvement
at 12-way.

https://www.gelato.unsw.edu.au/archives/scalability/2005-March/000069.html

Not sure what exactly would be going on at 8-way and above. Single
threaded lock hold times for find_lock_page should be fairly short... At
a wild guess, I'd say average lock transfer times are creeping up to the
point that spin lockers are taking multiple cacheline transfers to obtain
the lock, and the interconnect is getting saturated (read lockers should
only need one cacheline transfer in the absense of write lockers).

I thought Peter had a wider range of test cases than just reaim, but
perhaps that was for demonstrating some other problem.

Before that, Bill Irwin made some noises about Oracle improvements with
their VLM mode... that's not such a simple one to reproduce.

I'm sure SGI would be mortified too, but that's a given ;)

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/