[Top] [All Lists]

Re: [patch 2/2] xfs: use scalable vmap API

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [patch 2/2] xfs: use scalable vmap API
From: Nick Piggin <npiggin@xxxxxxx>
Date: Mon, 25 Jan 2010 19:33:09 +1100
Cc: xfs@xxxxxxxxxxx, linux-mm@xxxxxxxxx
In-reply-to: <20100125081750.GA20012@xxxxxxxxxxxxx>
References: <20081021082542.GA6974@xxxxxxxxxxxxx> <20081021082735.GB6974@xxxxxxxxxxxxx> <20081021120932.GB13348@xxxxxxxxxxxxx> <20081022093018.GD4359@xxxxxxxxxxxxx> <20100119121505.GA9428@xxxxxxxxxxxxx> <20100125075445.GD19664@laptop> <20100125081750.GA20012@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Mon, Jan 25, 2010 at 03:17:50AM -0500, Christoph Hellwig wrote:
> On Mon, Jan 25, 2010 at 06:54:45PM +1100, Nick Piggin wrote:
> > Is this on a 32-bit system with small vmalloc area?
> Yes.

OK, I would say it could easily be just due to fragmentation then.

> > When the vmap allocation fails, it would be good to basically see the
> > alloc_map and dirty_map for each of the vmap_blocks. This is going to be
> > a lot of information. Basically for all blocks with
> > free+dirty == VMAP_BBMAP_BITS are ones that could be released and you
> > could try the alloc again.
> Any easy way to get them?  Sorry, not uptodate on your new vmalloc
> implementation anymore.

Let me try writing a few (tested) patches here first that I can send you.

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