Messages in this thread |  | | | Date | Mon, 19 Apr 2010 23:09:50 +0900 | | Subject | Re: vmalloc performance | | From | Minchan Kim <> |
| |
On Mon, Apr 19, 2010 at 10:38 PM, Nick Piggin <npiggin@suse.de> 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 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/
|  |