xfs
[Top] [All Lists]

Re: [PATCH 4/6] xfs: optimize xfs_alloc_fix_freelist

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 4/6] xfs: optimize xfs_alloc_fix_freelist
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 28 Jan 2011 16:51:53 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20110128053653.GS21311@dastard>
References: <20110121092227.115815324@xxxxxxxxxxxxxxxxxxxxxx> <20110121092551.185804716@xxxxxxxxxxxxxxxxxxxxxx> <20110128053653.GS21311@dastard>
User-agent: Mutt/1.5.20 (2009-06-14)
On Fri, Jan 28, 2011 at 04:36:53PM +1100, Dave Chinner wrote:
> Thinking through this a bit more - we don't need to do a busy search
> for metadata allocations - it's only necessary for metadata -> data
> extent transistions. Metadata modifications are all logged, so there
> is no need to force out the busy extent transaction if the next
> allocation is for metadata. If the new transaction hits the disk,
> then it will only be replayed if the previous transaction to free
> the extent is on the disk and has already been replayed.
> 
> Hence I think we only need to do a busy search in these cases for
> XFS_FREELIST_ALLOC when args->userdata == 0. The XFS_FREELIST_BTREE
> case is definitely a metadata allocation, so it seems to me that
> there is further scope for optimisation here. i.e. that allocbt ->
> freelist -> allocbt doesn't require a sync transaction to be issued.
> 
> The code as it stands looks good; the question is should we take
> this next step as well? Have I missed anything that makes this a bad
> thing to do, Christoph?

Oh, I see the next patch tries to address this. That'll learn me to
read the entire patch series through before commenting on any of
it. I'll take this discussion to that patch.... ;)

Cheers,,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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