From mboxrd@z Thu Jan  1 00:00:00 1970
From: Steven Whitehouse <swhiteho@redhat.com>
Date: Wed, 28 Jul 2010 18:51:19 +0100
Subject: [Cluster-devel] GFS2: Use kmalloc when possible for ->readdir()
	(try #2)
In-Reply-To: <20100728101327.88dbd7ac.akpm@linux-foundation.org>
References: <1280315752.2502.59.camel@localhost>
	<AANLkTinuOVp6dL4c06FyacXp7uGUWNFvGtAUqkYMtjqp@mail.gmail.com>
	<1280336183.2502.87.camel@localhost>
	<20100728101327.88dbd7ac.akpm@linux-foundation.org>
Message-ID: <1280339479.2502.90.camel@localhost>
List-Id: <cluster-devel.redhat.com>
To: cluster-devel.redhat.com
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

On Wed, 2010-07-28 at 10:13 -0700, Andrew Morton wrote:
> On Wed, 28 Jul 2010 17:56:23 +0100 Steven Whitehouse <swhiteho@redhat.com> wrote:
> 
> > +static void *gfs2_alloc_sort_buffer(unsigned size)
> > +{
> > +	void *ptr = NULL;
> > +
> > +	if (size < KMALLOC_MAX_SIZE)
> > +		ptr = kmalloc(size, GFP_NOFS | __GFP_NOWARN);
> > +	if (!ptr)
> > +		ptr = __vmalloc(size, GFP_NOFS, PAGE_KERNEL);
> > +	return ptr;
> > +}
> > +
> > +static void gfs2_free_sort_buffer(void *ptr)
> > +{
> > +	if (is_vmalloc_addr(ptr))
> > +		vfree(ptr);
> > +	else
> > +		kfree(ptr);
> > +}
> 
> This got kicked around a bit in May (Subject: mm: generic adaptive
> large memory allocation APIs).  That patch tried kmalloc(), then
> alloc_pages(), then vmalloc().  Nothing got merged though.
> 
> I wasn't terribly excited about it because of vague fears that it would
> just incite people to spend even less effort thinking about how large
> their individual allocations are.
> 
> apparmor has a private kvfree/kvmalloc.  Probably there are other
> versions floating around the tree as well.
> 

I did wonder about that too, but bearing in mind that the longer term
plan is to eliminate the vmalloc call, I wasn't sure it was worth doing,

Steve.