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
|