On Thu, Jul 01, 2010 at 09:49:14AM +0100, Steven Whitehouse wrote: > Hi, > > On Wed, 2010-06-30 at 16:26 -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. > > Barry is running a benchmark test against GFS2 which simulates NFS > activity on the filesystem. Without this patch, the GFS2 ->readdir() > function (the only part of GFS2 which uses vmalloc) runs so slowly that > the test does not complete. With the patch, the test runs the same speed > as it did on earlier kernels. It would have been due to the commit I referenced. > I don't have an exact pointer to when the regression was introduced, but > it was after RHEL5 branched. OK the patch should be pretty fine to go into RHEL5, I'd think. Interesting that it slowed down so much for you. I would say this is due to a few differences between your testing and mine. Firstly, I was using a 64 CPU machine, and hammering vmap flushing on all CPUs. TLB broadcasting and flushing cost is going to be much much higher because there is an O(n^2) effect (N CPUs worth of work, each unit of work requires TLB flush to N CPUs). Interconnect cost would be much higher too compared to your 2s8c machine. So the cost of searching vmaps would be more hidden by the gains from avoiding flushing. Secondly, you were testing with probably 4K vmallocs. Wheras I was using 64K vmallocs on a 16KB page size machine with XFS. So in your testing there would be significantly more vmaps build up, by a factor of 10. Your workload is similar to Avi's as well. So in summary, I should have paid attention to the search complexity aspect and designed cases specifically to test that aspect. Oh well... thanks for the reporting and testing :) -- 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>