On Tue, Jul 04, 2006 at 11:57:43AM +0200, Ingo Molnar wrote: > > Right... but that leaves plenty that don't, and they're not simple to > > change. There are generic routines that need to be called from > > different contexts with different locking requirements (xfs_iget). > > the main variation in xfs_iget() is whether we lock the inode > read-write, read-only or not at all, correct? (XFS_ILOCK_EXCL, > XFS_ILOCK_SHARED and 0) > > That could be cleaned up the following way: *nod*. One difficulty is that xfs_iget_core would also need this treatment (the lock_mode parameter is passed down there), and we may end up be with quite a few functions and/or duplicated code. But maybe that can be avoided by arranging that code differently. > NOTE: since the majority (9 out of 13) of xfs_iget() uses are for the > 'no lock' variant, this construction of functions, besides making the > code more readable, _further_ reduces overhead, because there is no > ilock-flags checking overhead in __xfs_iget() anymore. Indeed; its fairly minimal overhead though really, the readability angle appeals to me more. Its just a fair bit of churn for not a very tangible gain, so I'm balking at it atm. Russell is looking at reworking xfs_iget for other reasons, so maybe he can stew on all of this and clean it up in the context of his other changes in there. Thanks Ingo. cheers. -- Nathan - 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
