[Top] [All Lists]

Re: [PATCH] xfs: improve xfs_iext_destroy() by freeing extent indirectio

To: Jeff Liu <jeff.liu@xxxxxxxxxx>
Subject: Re: [PATCH] xfs: improve xfs_iext_destroy() by freeing extent indirection array directly
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 24 Sep 2013 09:50:17 +1000
Cc: "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <523FCA18.1000204@xxxxxxxxxx>
References: <523C5E92.8000406@xxxxxxxxxx> <20130923003617.GM12541@dastard> <523FCA18.1000204@xxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Sep 23, 2013 at 12:56:56PM +0800, Jeff Liu wrote:
> On 09/23/2013 08:36 AM, Dave Chinner wrote:
> > On Fri, Sep 20, 2013 at 10:41:22PM +0800, Jeff Liu wrote:
> >> From: Jie Liu <jeff.liu@xxxxxxxxxx>
> >>
> >> To free the incore file extents stores at the indirection array, we
> >> call the common routine xfs_iext_irec_remove() to remove a record
> >> from the array one at a time in reverse order, which will resize an
> >> extent indirection array repeatedly according to the array size.
> >>
> >> This is not often the case to make a file with thousands extent records
> >> stores at an indirection array, but above operation is inefficient and
> >> could result in memory fragments.
> > 
> > Yes, it may be inefficient, but I don't see that it's a contributor
> > to memory fragmentation as the reallocated buffer is freed shortly
> > after it has been allocated as the array shrinks. Do you have any
> > evidence to suggest that such behaviour is actually fragmenting
> > memory? If so, is the any test case that reproduces this problem?
> Ah, yes, it should not cause memory fragmentation.
> The benefits is that this change could save alloc/free buffers depending
> on the number of extents records are stored at indirection array.

OK, can you send a new version with an updated commit message?


Dave Chinner

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