Miklos Szeredi <[email protected]> writes:

> On Sat, Feb 15, 2014 at 01:39:22PM -0800, Eric W. Biederman wrote:
>> 
>> Now that d_invalidate is the only caller of check_submounts_and_drop,
>> expand check_submounts_and_drop inline in d_invalidate.
>> 
>> Signed-off-by: "Eric W. Biederman" <[email protected]>
>> ---
>>  fs/dcache.c            |   55 
>> +++++++++++++++++++----------------------------
>>  include/linux/dcache.h |    1 -
>>  2 files changed, 22 insertions(+), 34 deletions(-)
>> 
>> diff --git a/fs/dcache.c b/fs/dcache.c
>> index 27585b1dd6f1..5b41205cbf33 100644
>> --- a/fs/dcache.c
>> +++ b/fs/dcache.c

>> -int check_submounts_and_drop(struct dentry *dentry)
>> +int d_invalidate(struct dentry *dentry)
>>  {
>>      int ret = 0;
>>  
>> +    /*
>> +     * If it's already been dropped, return OK.
>> +     */
>> +    spin_lock(&dentry->d_lock);
>> +    if (d_unhashed(dentry)) {
>> +            spin_unlock(&dentry->d_lock);
>> +            return 0;
>> +    }
>> +    spin_unlock(&dentry->d_lock);
>> +
>>      /* Negative dentries can be dropped without further checks */
>>      if (!dentry->d_inode) {
>>              d_drop(dentry);
>
>
> You can optimize this by including the negative check within the above 
> d_locked
> region and calling __d_drop() instead.

For this patch just moving the code and not changing it is the corret
thing to do because it helps with review and understanding the code.

There are two ways I could see going with optimizing the preamble.
Simply dropping the d_lock from around the d_unhashed test as a pointer
dereference should be atomic, and the test is racy against
d_materialise_unique. (We don't always hold the parent
directories inode mutex when d_invalidate is called).  So the d_lock
buys us very little.  Alternatively we could move the work into the
d_walk callbacks.

That kind of optimization deserves it's own patch that can be reviewed
independently.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to