[Top] [All Lists]

Re: [PATCH 08/16] xfs: implement lazy removal for the dquot freelist

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 08/16] xfs: implement lazy removal for the dquot freelist
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 5 Dec 2011 15:32:31 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20111128082837.638600213@xxxxxxxxxxxxxxxxxxxxxx>
References: <20111128082722.604873274@xxxxxxxxxxxxxxxxxxxxxx> <20111128082837.638600213@xxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Nov 28, 2011 at 03:27:30AM -0500, Christoph Hellwig wrote:
> Do not remove dquots from the freelist when we grab a reference to them in
> xfs_qm_dqlookup, but leave them on the freelist util scanning notices that
> they have a reference.  This speeds up the lookup fastpath, and greatly
> simplifies the lock ordering constraints.  Note that the same scheme is
> used by the VFS inode and dentry caches.
> Signed-off-by: Christoph Hellwig <hch@xxxxxx>

That cleans things up nicely, and should be significantly faster if
the VFS cache examples are anything to go by....

Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>

As an aside:

> +             /*
> +              * move the dquot to the front of the hashchain
> +              */
> +             list_move(&dqp->q_hashlist, &qh->qh_list);
> +             trace_xfs_dqlookup_done(dqp);
> +             *O_dqpp = dqp;
> +             return 0;

Back when the inode cache used a hash, we found that this moving of
the item to the front of the list actually slowed down lookups - the
impact of dirtying cachelines (i.e. remote CPU cache invalidation)
to move the item in the list was greater than the time saved during
lookups. That was because that when there are no hash chain
modifications taking place, then the frequently hit chains simply
end up shared in all the cpu caches rather than being turfed out on
every successful lookup on a different CPU....


Dave Chinner

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