Messages in this thread |  | | | Date | Fri, 20 Sep 2002 23:10:20 +0530 | | From | Dipankar Sarma <> | | Subject | Re: 2.5.36-mm1 dbench 512 profiles |
| |
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.
Thanks -- Dipankar Sarma <dipankar@in.ibm.com> http://lse.sourceforge.net 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |