Re: [PATCH 2/9] inode: add IOP_NOTHASHED to avoid inode hash lock in evict

From: Josef Bacik
Date: Thu Mar 12 2015 - 08:24:29 EST


On 03/12/2015 05:52 AM, Al Viro wrote:
On Tue, Mar 10, 2015 at 03:45:17PM -0400, Josef Bacik wrote:
From: Dave Chinner <dchinner@xxxxxxxxxx>

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 an inode opflag to allow inode_hash_remove() to
avoid taking the hash lock on inodes have never actually been
hashed.

Why bother with flags, etc. when we could just do

static inline bool hlist_fake(struct hlist_node *h)
{
return h->pprev == &h->next;
}

- if (!inode_unhashed(inode))
+ if (!((inode->i_opflags & IOP_NOTHASHED) || inode_unhashed(inode)))

and turn this check into
if (!inode_unhashed(inode) && !hlist_fake(&inode->i_hash))

instead?


I made the change and sent the new patch, hopefully it worked, sometimes my laptop screws up git-send-email. If everything looks good to you Al you can pull from my tree if you don't want to scrape from the list

git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git superblock-scaling

Thanks,

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