On Tue, Aug 17, 2010 at 07:14:42PM -0400, Valerie Aurora wrote: > On Wed, Aug 18, 2010 at 04:37:33AM +1000, Nick Piggin wrote: > > - read_lock(¤t->fs->lock); > > + spin_lock(¤t->fs->lock); > > root = dget(current->fs->root.dentry); > > - read_unlock(¤t->fs->lock); > > + spin_unlock(¤t->fs->lock); > > > > spin_lock(&dcache_lock); > > Your reasoning makes sense to me. Shared reader access seems very > unlikely whereas the cost of taking the lock is certain. Yes, shared reader will only help if we have multiple threads inside the critical section at the same time, and if they can actually get any extra parallelism (which they can't, because all they're doing here is just hitting another contended cacheline). I doubt this will change scalability at all, but it will improve single threaded performance a little bit. With the store-free path walk, I can actually do some tricks to entirely remove the fs->lock spinlock in the common case here (using a seqlock instead). Combined with avoiding refcounts to the cwd, so it avoids all the contention between threads. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
