On Wed, 14 Dec 2011, Alex,Shi wrote: > > 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. :) Well yes we have been back and forth on hot/cold page things repeatedly in the page allocator as well. Caching is not always good. There are particular loads that usually do very well with caching. Others do not. Caching can cause useless processing and pollute caching. It is also a cause for OS noise due to cache maintenance at random (for the app guys) times where they do not want that to happen. > > 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? Many people have done patchsets like this. There are various permutations on SL?B (I dont remember them all SLEB, SLXB, SLQB etc) that have been proposed over the years. Caches tend to grow and get rather numerous (see SLAB) and the design of SLUB was to counter that. There is a reason it was called SLUB. The U stands for Unqueued and was intended to avoid the excessive caching problems that I ended up when reworking SLAB for NUMA support. -- 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>