xfs
[Top] [All Lists]

Re: [PATCH] [RFC] xfs: lookaside cache for xfs_buf_find

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH] [RFC] xfs: lookaside cache for xfs_buf_find
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Thu, 19 Sep 2013 08:23:32 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130918232409.GF9901@dastard>
References: <1378690396-15792-1-git-send-email-david@xxxxxxxxxxxxx> <523A1FBD.4010701@xxxxxxx> <20130918232409.GF9901@dastard>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 09/18/13 18:24, Dave Chinner wrote:
On Wed, Sep 18, 2013 at 04:48:45PM -0500, Mark Tinguely wrote:
On 09/08/13 20:33, Dave Chinner wrote:
From: Dave Chinner<dchinner@xxxxxxxxxx>

CPU overhead of buffer lookups dominate most metadata intensive
workloads. The thing is, most such workloads are hitting a
relatively small number of buffers repeatedly, and so caching
recently hit buffers is a good idea.

Add a hashed lookaside buffer that records the recent buffer
lookup successes and is searched first before doing a rb-tree
lookup. If we get a hit, we avoid the expensive rbtree lookup and
greatly reduce the overhead of the lookup. If we get a cache miss,
then we've added an extra CPU cacheline miss into the lookup.
....

Low cost, possible higher return. Idea looks good to me.

What happens in xfs_buf_get_map() when we lose the xfs_buf_find() race?

What race is that?

I am thinking the two overlapping callers to xfs_buf_find() protected by the two calls to xfs_buf_find(). But my mistake was where the lookaside gets added. It is added correctly on the second call to xfs_buf_find() where it make sure that another find did not beat this find. Yes, no entry needs to be removed.


--Mark.

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