On Wed, Jun 30, 2010 at 04:26:02PM -0700, Andrew Morton wrote: > On Sat, 26 Jun 2010 18:31:22 +1000 > Nick Piggin <npiggin@xxxxxxx> wrote: > > > On Fri, Jun 25, 2010 at 02:00:17PM +0100, Steven Whitehouse wrote: > > > Hi, > > > > > > Barry Marson has now tested your patch and it seems to work just fine. > > > Sorry for the delay, > > > > > > Steve. > > > > Hi Steve, > > > > Thanks for that, do you mean that it has solved thee regression? > > Nick, can we please have an updated changelog for this patch? I didn't > even know it fixed a regression (what regression?). Barry's tested-by: > would be nice too, along with any quantitative results from that. > > Thanks. Sure. It is a performance regression caused by the lazy vunmap patches which went in a while back. So it's appropriate for 2.6.36, and then probably distros will want to backport it, if not -stable. How's this? -- mm: vmalloc add a free area cache for vmaps Provide a free area cache for the vmalloc virtual address allocator, based on the algorithm used by the user virtual memory allocator. This reduces the number of rbtree operations and linear traversals over the vmap extents in order to find a free area, by starting off at the last point that a free area was found. The free area cache is reset if areas are freed behind it, or if we are searching for a smaller area or alignment than last time. So allocation patterns are not changed (verified by corner-case and random test cases in userspace testing). This solves a regression caused by lazy vunmap TLB purging introduced in db64fe02 (mm: rewrite vmap layer). That patch will leave extents in the vmap allocator after they are vunmapped, and until a significant number accumulate that can be flushed in a single batch. So in a workload that vmalloc/vfree frequently, a chain of extents will build up from VMALLOC_START address, which have to be iterated over each time (giving an O(n) type of behaviour). After this patch, the search will start from where it left off, giving closer to an amortized O(1). This is verified to solve regressions reported Steven in GFS2, and Avi in KVM. Signed-off-by: Nick Piggin <npiggin@xxxxxxx> Reviewed-by: Minchan Kim <minchan.kim@xxxxxxxxx> Reported-and-tested-by: Steven Whitehouse <swhiteho@xxxxxxxxxx> Reported-and-tested-by: Avi Kivity <avi@xxxxxxxxxx> -- 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>