xfs
[Top] [All Lists]
<prev [Date] next>
[Advanced]
 <prev [Thread] next>

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

from [Christoph Hellwig] [Permanent Link][Original]
To: Nick Piggin <npiggin@xxxxxxx>
Subject: Re: [patch 2/2] xfs: use scalable vmap API
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 19 Jan 2010 07:15:05 -0500
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, linux-mm@xxxxxxxxx
In-reply-to: <20081022093018.GD4359@xxxxxxxxxxxxx>
References: <20081021082542.GA6974@xxxxxxxxxxxxx> <20081021082735.GB6974@xxxxxxxxxxxxx> <20081021120932.GB13348@xxxxxxxxxxxxx> <20081022093018.GD4359@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.19 (2009-01-05) 
Hi Nick,

I've looked into retesting and re-enabling the swithc to your
scalabale vmap API (original commit 95f8e302c04c0b0c6de35ab399a5551605eeb006).

The good thing is that I can't reproduce the original regressions in
xfstests I've seen.  The bad news is that starting from the second
consequitive xfstests run we're not able to vmalloc the log buffers
anymore.  It seems the use of this API introduces some leak of vmalloc
space.  Any idea how to debug this further?
[More with this subject...]
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date:  Re: [PATCH 8/8] xfs: make compile warn about char sign mismatches again, Dave Chinner
Next by Date:  Re: [PATCH 1/3] [PATCH] xfs: remove duplicate buffer flags, Dave Chinner
Previous by Thread:  [PATCH 0/3] random cleanups for 2.6.34, Christoph Hellwig
Next by Thread:  Re: [patch 2/2] xfs: use scalable vmap API, Nick Piggin
Indexes:  [Date] [Thread] [Top] [All Lists]