Date: Mon, 19 Apr 2010 23:38:43 +1000
From: Nick Piggin <npiggin@suse.de>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Steven Whitehouse <swhiteho@redhat.com>, linux-mm@kvack.org,
       linux-kernel@vger.kernel.org
Subject: Re: vmalloc performance
Message-ID: <20100419133843.GP5683@laptop>
References: <1271089672.7196.63.camel@localhost.localdomain>
 <1271249354.7196.66.camel@localhost.localdomain>
 <m2g28c262361004140813j5d70a80fy1882d01436d136a6@mail.gmail.com>
 <1271262948.2233.14.camel@barrios-desktop>
 <1271320388.2537.30.camel@localhost>
 <1271350270.2013.29.camel@barrios-desktop>
 <1271427056.7196.163.camel@localhost.localdomain>
 <1271603649.2100.122.camel@barrios-desktop>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1271603649.2100.122.camel@barrios-desktop>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1931
Lines: 42

On Mon, Apr 19, 2010 at 12:14:09AM +0900, Minchan Kim wrote:
> On Fri, 2010-04-16 at 15:10 +0100, Steven Whitehouse wrote:
> Nick, What do you think about "free area cache" approach?
 
Thanks, yep something like this is what I had in mind. Looks like you
have some really nice speed improvements which is great.


> In this version, I don't consider last hole and backward cache movement which is 
> like mmap's cached_hole_size
> That's because I want to flush vmap_areas freed intentionally if we meet vend.
> It makes flush frequent than old but it's trade-off. In addition, vmalloc isn't 
> critical compared to mmap about performance. So I think that's enough. 
> 
> If you don't opposed, I will repost formal patch without code related to debug.

I think I would prefer to be a little smarter about using lower
addresses first. I know the lazy TLB flushing works against this, but
that is an important speed tradeoff, wheras there is not really any
downside to trying hard to allocate low areas first. Keeping virtual
addresses dense helps with locality of reference of page tables, for
one.

So I would like to see:
- invalidating the cache in the case of vstart being decreased.
- Don't unconditionally reset the cache to the last vm area freed,
  because you might have a higher area freed after a lower area. Only
  reset if the freed area is lower.
- Do keep a cached hole size, so smaller lookups can restart a full
  search.

Probably also at this point, moving some of the rbtree code (like the
search code) into functions would manage the alloc_vmap_area complexity.
Maybe do this one first if you're going to write a patchset.

What do you think? Care to have a go? :)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/