> > Thanks for the data. Real netperf is hard to give enough press on SLUB. > > but as I mentioned before, I also didn't find real performance change on > > my loopback netperf testing. > > > > I retested hackbench again. about 1% performance increase still exists > > on my 2 sockets SNB/WSM and 4 sockets NHM. and no performance drop for > > other machines. > > > > Christoph, what's comments you like to offer for the results or for this > > code change? > > I believe far more aggressive mechanism is needed to help these > workloads. > > Please note that the COLD/HOT page concept is not very well used in > kernel, because its not really obvious that some decisions are always > good (or maybe this is not well known) Hope Christoph know everything of SLUB. :) > > We should try to batch things a bit, instead of doing a very small unit > of work in slow path. > > We now have a very fast fastpath, but inefficient slow path. > > SLAB has a litle cache per cpu, we could add one to SLUB for freed > objects, not belonging to current slab. This could avoid all these > activate/deactivate overhead. Maybe worth to try or maybe Christoph had studied this? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>