Date: Wed, 3 Sep 2008 09:06:54 +0200
From: Andi Kleen <andi@firstfloor.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Andi Kleen <andi@firstfloor.org>, lachlan@sgi.com,
        xfs-dev <xfs-dev@sgi.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] Tweak tracing allocation sizes
Message-ID: <20080903070654.GP18288@one.firstfloor.org>
References: <48BCD3BE.5040107@sgi.com> <20080902055604.GD15962@disturbed> <48BCD93E.9040407@sgi.com> <87fxojvy5v.fsf@basil.nowhere.org> <20080902215516.GE9204@infradead.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080902215516.GE9204@infradead.org>
User-Agent: Mutt/1.4.2.1i

On Tue, Sep 02, 2008 at 05:55:16PM -0400, Christoph Hellwig wrote:
> On Tue, Sep 02, 2008 at 08:50:52AM +0200, Andi Kleen wrote:
> > > alternative - maybe a very large global trace buffer that is allocated at mount
> > > time and shared by all inodes?
> > 
> > You could use vmalloc(). While that is also not fast it will at least
> > not stall.
> 
> In fact kmem_alloc first tries vmalloc, and then falls back to slab
> when it fails.  See fs/xfs/linux-2.6/kmem.c:kmem_alloc().

You mean the other way around? 

Anyways it sounds like like MAX_SLAB_SIZE is just too big.

-Andi