[Top] [All Lists]

Re: [PATCH 2/3] xfs: convert inode cache lookups to use RCU locking

To: Nick Piggin <npiggin@xxxxxxxxx>
Subject: Re: [PATCH 2/3] xfs: convert inode cache lookups to use RCU locking
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 15 Dec 2010 17:35:34 +1100
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <loom.20101215T041848-135@xxxxxxxxxxxxxx>
References: <1292203957-15819-1-git-send-email-david@xxxxxxxxxxxxx> <1292203957-15819-3-git-send-email-david@xxxxxxxxxxxxx> <20101214211801.GH2161@xxxxxxxxxxxxxxxxxx> <20101214230047.GC16267@dastard> <20101215010536.GT2161@xxxxxxxxxxxxxxxxxx> <loom.20101215T041848-135@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Wed, Dec 15, 2010 at 03:30:43AM +0000, Nick Piggin wrote:
> In this case, if you can observe something that has happened after the
> inode is removed from the tree (ie. i_ino has changed), then you should
> not find it in the tree after a subsequent lookup (no synchronize_rcu
> required, just appropriate locking or barriers).

Ok, that's what I thought was supposed to be the case. Thanks
for confirming that, Nick.

> BTW. I wondered if you can also do the radix_tree tag lookup for reclaim
> under RCU?

It's currently under the ->pag_ici_lock using a
radix_tree_gang_lookup_tag, though I think this was a mismerge bug
from an earlier version.

I intended it to be under RCU as the "inode OK for reclaim"
validation checks won't touch an inode that already has XFS_IRECLAIM
already set (i.e. already under reclaim or freed), so the
reliability of tag lookups is not a big deal.

The lookup probably needs to check if XFS_IRECLAIMABLE is set
(rather than asserting it is set) to avoid so as to only reclaim
inodes that are really in the reclaimable state. Note that
->i_flags_lock controls all the state changes, so it should provide
the necessary item memory barriers to ensure that only reclaimable
inodes are found for reclaim.


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>