| To: | Nick Piggin <npiggin@xxxxxxx> |
|---|---|
| Subject: | Re: [patch 2/2] xfs: use scalable vmap API |
| From: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
| Date: | Mon, 25 Jan 2010 03:17:50 -0500 |
| Cc: | Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, linux-mm@xxxxxxxxx |
| In-reply-to: | <20100125075445.GD19664@laptop> |
| References: | <20081021082542.GA6974@xxxxxxxxxxxxx> <20081021082735.GB6974@xxxxxxxxxxxxx> <20081021120932.GB13348@xxxxxxxxxxxxx> <20081022093018.GD4359@xxxxxxxxxxxxx> <20100119121505.GA9428@xxxxxxxxxxxxx> <20100125075445.GD19664@laptop> |
| User-agent: | Mutt/1.5.19 (2009-01-05) |
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. > 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. |
| <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 2/2] xfs: use scalable vmap API, Nick Piggin |
| Previous by Thread: | Re: [patch 2/2] xfs: use scalable vmap API, Nick Piggin |
| Next by Thread: | Re: [patch 2/2] xfs: use scalable vmap API, Nick Piggin |
| Indexes: | [Date] [Thread] [Top] [All Lists] |