Re: 2.5.36-mm1 dbench 512 profiles

From: Dipankar Sarma (
Date: Fri Sep 20 2002 - 12:40:20 EST

On Fri, Sep 20, 2002 at 02:37:41PM +0000, Dave Hansen wrote:
> Isn't increased hold time _good_ on NUMA-Q? I thought that the really
> costy operation was bouncing the lock around the interconnect, not

Increased hold time isn't necessarily good. If you acquire the lock
often, your lock wait time will increase correspondingly. The ultimate
goal should be to decrease the total number of acquisitions.

> holding it. Has fastwalk ever been tested on NUMA-Q?

Fastwalk is in 2.5. You can see wli's profile numbers for dbench 512
earlier in this thread.

> Remember when John Stultz tried MCS (fair) locks on NUMA-Q? They
> sucked because low hold times, which result from fairness, aren't
> efficient. It is actually faster to somewhat starve remote CPUs.

One workaround is to keep scheduling the lock within the CPUs of
a node as much as possible and release it to a different node
only if there isn't any CPU available in the current node. Anyway
these are not real solutions, just band-aids.

> In any case, we all know often acquired global locks are a bad idea on
> a 32-way, and should be avoided like the plague. I just wish we had a
> dcache solution that didn't even need locks as much... :)

You have one - dcache_rcu. It reduces the dcache_lock acquisition
by about 65% over fastwalk.


Dipankar Sarma  <>
Linux Technology Center, IBM Software Lab, Bangalore, India.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:31 EST