From: Jeff Liu <jeff.liu@oracle.com>
To: Dave Chinner <david@fromorbit.com>
Cc: "xfs@oss.sgi.com" <xfs@oss.sgi.com>
Subject: Re: [PATCH] xfs: improve xfs_iext_destroy() by freeing extent indirection array directly
Date: Mon, 23 Sep 2013 12:56:56 +0800 [thread overview]
Message-ID: <523FCA18.1000204@oracle.com> (raw)
In-Reply-To: <20130923003617.GM12541@dastard>
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@oracle.com>
>>
>> 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.
>
> How did you test the change?
I only test this change with a simple case for creating a sparse file
with 8192 extents, which was shown as following,
xfs_io -f -c "truncate 10g" /xfs/testme
for i in $(seq 0 1 8191); do
offset=$(($i * $((1 << 20))))
xfs_io -c "pwrite $offset 1k" /xfs/testme
done
>
>> This patch refine xfs_iext_destroy() by freeing the extent records from
>> the indirection array directly in this case.
>>
>> Signed-off-by: Jie Liu <jeff.liu@oracle.com>
>> ---
>
> FWIW, it is best to title a resend as [PATCH x/y, V2], and here tell
> us what changed between posts such as:
>
> V2:
> - fixed typo in original posting
Ok. :)
Thanks,
-Jeff
>
>> fs/xfs/xfs_inode_fork.c | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/xfs/xfs_inode_fork.c b/fs/xfs/xfs_inode_fork.c
>> index 02f1083..ba70f98 100644
>> --- a/fs/xfs/xfs_inode_fork.c
>> +++ b/fs/xfs/xfs_inode_fork.c
>> @@ -1525,9 +1525,12 @@ xfs_iext_destroy(
>> int nlists;
>>
>> nlists = ifp->if_real_bytes / XFS_IEXT_BUFSZ;
>> - for (erp_idx = nlists - 1; erp_idx >= 0 ; erp_idx--) {
>> - xfs_iext_irec_remove(ifp, erp_idx);
>> + for (erp_idx = 0; erp_idx < nlists; erp_idx++) {
>> + xfs_ext_irec_t *erp = &ifp->if_u1.if_ext_irec[erp_idx];
>> + if (erp->er_extbuf)
>> + kmem_free(erp->er_extbuf);
>> }
>> + kmem_free(ifp->if_u1.if_ext_irec);
>
>
> The code looks correct...
>
> Cheers,
>
> Dave.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-09-23 4:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-20 14:41 [PATCH] xfs: improve xfs_iext_destroy() by freeing extent indirection array directly Jeff Liu
2013-09-23 0:36 ` Dave Chinner
2013-09-23 4:56 ` Jeff Liu [this message]
2013-09-23 23:50 ` Dave Chinner
2013-09-24 14:05 ` Jeff Liu
-- strict thread matches above, loose matches on Subject: below --
2013-09-20 13:21 Jeff Liu
2013-09-20 14:39 ` Jeff Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=523FCA18.1000204@oracle.com \
--to=jeff.liu@oracle.com \
--cc=david@fromorbit.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.