| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: [patch 2/2] xfs: use scalable vmap API, Nick Piggin |
|---|---|
| Next by Date: | Re: [PATCH] xfs: turn off sign warnings, Christoph Hellwig |
| Previous by Thread: | Re: [patch 2/2] xfs: use scalable vmap API, Christoph Hellwig |
| Next by Thread: | Re: [patch 2/2] xfs: use scalable vmap API, Nick Piggin |
| Indexes: | [Date] [Thread] [Top] [All Lists] |