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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
