Re: [PATCH 02/17] fs: icache lock s_inodes list

[Nick Piggin]

On Sat, Oct 16, 2010 at 12:12:10PM -0400, Christoph Hellwig wrote:
> On Sat, Oct 16, 2010 at 06:54:11PM +1100, Nick Piggin wrote:
> > Because in the first part of the inode lock series, it is breaking
> > locks in obvious small steps as possible, by adding global locks
> > protecting bits of what inode_lock used to.
> 
> As seen by Dave's respin making it per-sb was just as easy as making
> it global. And it really is the logical synchronization domain.

If you want it to be scalable within a single sb, it needs to be
per cpu. If it is per-cpu it does not need to be per-sb as well
which just adds bloat.

And the entire idea of the first half of the inode series is that
it starts simple and just uses globals to demonstrate the locking
steps. It's obviously not supposed to be a "production" locking
model so I prefer it to be like that.

--
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/