[Top] [All Lists]

Re: [PATCH 4/5] repair: don't cache large blkmap allocations

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 4/5] repair: don't cache large blkmap allocations
From: Alex Elder <aelder@xxxxxxx>
Date: Thu, 13 Oct 2011 04:57:57 -0500
Cc: <xfs@xxxxxxxxxxx>
In-reply-to: <1318208915-14975-5-git-send-email-david@xxxxxxxxxxxxx>
References: <1318208915-14975-1-git-send-email-david@xxxxxxxxxxxxx> <1318208915-14975-5-git-send-email-david@xxxxxxxxxxxxx>
Reply-to: <aelder@xxxxxxx>
On Mon, 2011-10-10 at 12:08 +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@xxxxxxxxxx>
> We currently use thread local storage for storing blkmap allocations
> from one inode to another as a way of reducing the number of short
> term allocations we do. However, the stored allocations can only
> ever grow, so once we've done a large allocation we never free than
> memory even if we never need that much memory again. This can occur
> if we have corrupted extent counts in inodes, and can greatly
> increase the memory footprint of the repair process.
> Hence if the cached blkmap array id greater than a reasonable number
> of extents (say 100,000), then don't store the blkmap in TLS and
> instead free it.
> Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>

Looks good.

Reviewed-by: Alex Elder <aelder@xxxxxxx>

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