[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110824062706.GD24077@infradead.org>
Date: Wed, 24 Aug 2011 02:27:06 -0400
From: Christoph Hellwig <hch@...radead.org>
To: Dave Chinner <david@...morbit.com>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-mm@...ck.org, khlebnikov@...nvz.org
Subject: Re: [PATCH 10/13] xfs: convert buftarg LRU to generic code
> -STATIC void
> +static inline void
> xfs_buf_lru_add(
> struct xfs_buf *bp)
> {
> - struct xfs_buftarg *btp = bp->b_target;
> -
> - spin_lock(&btp->bt_lru_lock);
> - if (list_empty(&bp->b_lru)) {
> + if (list_lru_add(&bp->b_target->bt_lru, &bp->b_lru))
> atomic_inc(&bp->b_hold);
> - list_add_tail(&bp->b_lru, &btp->bt_lru);
> - btp->bt_lru_nr++;
> - }
> - spin_unlock(&btp->bt_lru_lock);
> }
Is there any point in keeping this wrapper?
> +static inline void
> xfs_buf_lru_del(
> struct xfs_buf *bp)
> {
> if (list_empty(&bp->b_lru))
> return;
>
> + list_lru_del(&bp->b_target->bt_lru, &bp->b_lru);
> }
It seems like all callers of list_lru_del really want the unlocked
check. Out of your current set only two of the inode.c callers
are missing it, but given that those set I_FREEING first they should
be safe to do it as well. What do you think about pulling
the unlocked check into list_lru_del?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists