On Wed, 14 Dec 2011, Eric Dumazet wrote: > > Many people have done patchsets like this. > > Things changed a lot recently. There is room for improvements. > > At least we can exchange ideas _before_ coding a new patchset ? Sure but I hope we do not simply rehash what has been said before and recode what others have code in years past. > > 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. > > Current 'one active slab' per cpu is a one level cache. > > It really is a _queue_ containing a fair amount of objects. In some sense you are right. It is a set of objects linked together. That can be called a queue and it has certain cache hot effects. It is not a qeueue in the SLAB sense meaning a configurable array of pointers. > My initial idea would be to use a cache of 4 slots per cpu, but be able > to queue many objects per slot, if they all belong to same slab/page. Nick did that. Please read up on his work. I think it was named SLQB. -- 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>