Messages in this thread | | | Date | Fri, 20 Sep 2002 23:18:42 +0530 | From | Dipankar Sarma <> | Subject | Re: 2.5.36-mm1 dbench 512 profiles |
| |
On Fri, Sep 20, 2002 at 04:17:10PM +0000, Martin J. Bligh 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 holding it. > > Depends what you get it return. The object of fastwalk was to stop the > cacheline bouncing on all the individual dentry counters, at the cost > of increased dcache_lock hold times. It's a tradeoff ... and in this > instance it wins. In general, long lock hold times are bad.
I don't think individual dentry counters are as much a problem as acquisition of dcache_lock for every path component lookup as done by the earlier path walking algorithm. The big deal with fastwalk is that it decreases the number of acquisitions of dcache_lock for a webserver workload by 70% on an 8-CPU machine. That is avoiding a lot of possible cacheline bouncing of dcache_lock.
> > 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... :) > > Well, avoiding data corruption is a preferable goal too. The point of > RCU is not to have to take a lock for the common read case. I'd expect > good results from it on the NUMA machines - never been benchmarked, as > far as I recall.
You can see that in wli's dbench 512 results on his NUMA box.
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/
| |