[Top] [All Lists]

Re: [PATCH] xfs: flush vmap aliases when mapping fails

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH] xfs: flush vmap aliases when mapping fails
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 11 Mar 2011 09:49:45 +1100
Cc: xfs@xxxxxxxxxxx, npiggin@xxxxxxxxx, linux-mm@xxxxxxxxx
In-reply-to: <20110310073751.GB25374@xxxxxxxxxxxxx>
References: <1299713876-7747-1-git-send-email-david@xxxxxxxxxxxxx> <20110310073751.GB25374@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Thu, Mar 10, 2011 at 02:37:51AM -0500, Christoph Hellwig wrote:
> On Thu, Mar 10, 2011 at 10:37:56AM +1100, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@xxxxxxxxxx>
> > 
> > On 32 bit systems, vmalloc space is limited and XFS can chew through
> > it quickly as the vmalloc space is lazily freed. This can result in
> > failure to map buffers, even when there is apparently large amounts
> > of vmalloc space available. Hence, if we fail to map a buffer, purge
> > the aliases that have not yet been freed to hopefuly free up enough
> > vmalloc space to allow a retry to succeed.
> IMHO this should be done by vm_map_ram internally.  If we can't get the
> core code fixes we can put this in as a last resort.

OK. The patch was done as part of the triage for this bug:


where the vmalloc space on 32 bit systems is getting exhausted. I
can easily move this flush-and-retry into the vmap code.

FWIW, while the VM folk might be paying attention about vmap realted
stuff, this vmap BUG() also needs triage:


And, finally, the mm-vmap-area-cache.patch in the current mmotm also
needs to be pushed forward because we've been getting reports of
excessive CPU time being spent walking the vmap area rbtree during
vm_map_ram operations and this patch supposedly fixes that


Dave Chinner

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