| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 3/5] repair: handle memory allocation failure from blkmap_grow, Alex Elder |
|---|---|
| Next by Date: | Re: [PATCH 5/5] repair: prevent blkmap extent count overflows, Alex Elder |
| Previous by Thread: | Re: [PATCH 4/5] repair: don't cache large blkmap allocations, Christoph Hellwig |
| Next by Thread: | Re: [PATCH 0/5, v3] repair: sector size and blkmap fixes, Christoph Hellwig |
| Indexes: | [Date] [Thread] [Top] [All Lists] |