On Mon, Apr 19, 2010 at 10:38 PM, Nick Piggin <npiggin@xxxxxxx> wrote: > 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. Firstly, I considered it which is used by mmap. But I thought it might be overkill since vmalloc space isn't large compared to mmaped addresses. I should have thought about locality of reference of page tables. ;-) > 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? :) Good. I will add your requirements to TODO list. But don't wait me. If you care to have a go, RUN!!! I am looking forward to seeing your awesome patches. :) Thanks for careful review, Nick. -- Kind regards, Minchan Kim -- 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