From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id o0P7rmwL042108 for ; Mon, 25 Jan 2010 01:53:49 -0600 Received: from mx2.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A6B03F48618 for ; Sun, 24 Jan 2010 23:54:50 -0800 (PST) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by cuda.sgi.com with ESMTP id 1BmxZaE6WXNS8m5k for ; Sun, 24 Jan 2010 23:54:50 -0800 (PST) Date: Mon, 25 Jan 2010 18:54:45 +1100 From: Nick Piggin Subject: Re: [patch 2/2] xfs: use scalable vmap API Message-ID: <20100125075445.GD19664@laptop> References: <20081021082542.GA6974@wotan.suse.de> <20081021082735.GB6974@wotan.suse.de> <20081021120932.GB13348@infradead.org> <20081022093018.GD4359@wotan.suse.de> <20100119121505.GA9428@infradead.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20100119121505.GA9428@infradead.org> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: Christoph Hellwig Cc: linux-mm@kvack.org, xfs@oss.sgi.com On Tue, Jan 19, 2010 at 07:15:05AM -0500, Christoph Hellwig wrote: > 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? Hi Christoph, OK, that's worrying. It's silly have all that vmap layer work in the tree and no users, not surprised to have a bug there. Is this on a 32-bit system with small vmalloc area? Basically in the scalable API implementation, we allocate per-CPU vmap chunks (struct vmap_block) from the normal global allocator, and then subsequently do allocations from those chunks using the simple bitmap allocator. Now there is more room for fragmentation with this approach, and a few problems that I should really fix: firstly, a chunk with say a 1 page hole left in it that is never used will never get freed. So it will be good to free those chunks. Secondly, one CPU should be able to steal from others if it can't find more memory. So if you have small vmalloc space, it could be just these issues making vmalloc consumption worse. Otherwise yes there could be a real leak there unrelated to fragmentation. 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. Thanks, Nick _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs