On Thu 12-03-15 08:20:23, Josef Bacik wrote:
> Some filesystems don't use the VFS inode hash and fake the fact they
> are hashed so that all the writeback code works correctly. However,
> this means the evict() path still tries to remove the inode from the
> hash, meaning that the inode_hash_lock() needs to be taken
> unnecessarily. Hence under certain workloads the inode_hash_lock can
> be contended even if the inode is never actually hashed.
>
> To avoid this add hlist_fake to test if the inode isn't actually
> hashed to avoid taking the hash lock on inodes that have never been
> hashed. Based on Dave Chinner's
>
> inode: add IOP_NOTHASHED to avoid inode hash lock in evict
>
> basd on Al's suggestions. Thanks,
>
> Signed-off-by: Josef Bacik <[email protected]>
Looks good. You can add:
Reviewed-by: Jan Kara <[email protected]>
Honza
> ---
> V1->V2: Argh sorry, forgot to reset the author, my bad.
>
> include/linux/fs.h | 2 +-
> include/linux/list.h | 5 +++++
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index b4d71b5..31da757 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2528,7 +2528,7 @@ static inline void insert_inode_hash(struct inode
> *inode)
> extern void __remove_inode_hash(struct inode *);
> static inline void remove_inode_hash(struct inode *inode)
> {
> - if (!inode_unhashed(inode))
> + if (!inode_unhashed(inode) && !hlist_fake(&inode->i_hash))
> __remove_inode_hash(inode);
> }
>
> diff --git a/include/linux/list.h b/include/linux/list.h
> index feb773c..3e3e64a 100644
> --- a/include/linux/list.h
> +++ b/include/linux/list.h
> @@ -672,6 +672,11 @@ static inline void hlist_add_fake(struct hlist_node *n)
> n->pprev = &n->next;
> }
>
> +static inline bool hlist_fake(struct hlist_node *h)
> +{
> + return h->pprev == &h->next;
> +}
> +
> /*
> * Move a list from one list head to another. Fixup the pprev
> * reference of the first entry if it exists.
> --
> 1.9.3
>
--
Jan Kara <[email protected]>
SUSE Labs, CR
--
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/
