![]() | |||||||||||||
Messages in this thread |
On Monday 02 January 2006 14:04, Pekka J Enberg wrote: > Maybe it's not. But that's besides the point. It was my point. I don't know what your point was. > The specific problem Bonwick > mentioned is related to cache line distribution and should be taken care > of by slab coloring. Internal fragmentation is painful but the worst > offenders can be fixed with kmem_cache_alloc(). So I really don't see the > problem. On the other hand, I am not opposed to dynamic generic slabs if > you can show a clear performance benefit from it. I just doubt you will. I wasn't proposing fully dynamic slabs, just a better default set of slabs based on real measurements instead of handwaving (like the power of two slabs seemed to have been generated). With separate sets for 32bit and 64bit. Also the goal wouldn't be better performance, but just less waste of memory. I suspect such a move could save much more memory on small systems than any of these "make fundamental debugging tools a CONFIG" patches ever. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-01-02 15:02 [from the cache] ©2003-2008 | |||||||||||||