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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>