On Mon, Jun 28, 2010 at 09:37:42AM +0100, Steven Whitehouse wrote: > Hi, > > On Sat, 2010-06-26 at 18:31 +1000, Nick Piggin 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? > > > > Thanks, > > Nick > > > > Yes, thats what I have heard from Barry. He said that it was pretty > close to the expected performance but did not give any figures. The fact > that his test actually completes shows that most of the problem has been > solved, Thanks, so I think it's good to go. It is interesting that it is just "close" to expected performance. The lazy vunmap patch is preventing a global IPI and TLB flush on all CPUs for every vfree() (amortizing it down to basically nothing if you are doing just small vmaps). Unless you are testing on a UP machine, I would have expected improved performance if you are doing a lot of vmalloc/vfree activity. It could be that the search is still taking some time, and is outweighing the gains. We have a few options for being cleverer, so if you're ever interested to get more detailed results and find a bit more performance here, let me know. And thanks for all the reporting and testing so far. -- 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>