On Tue, Oct 16, 2012 at 3:07 PM, Tim Bird <tim.bird@xxxxxxxxxxx> wrote: > On 10/16/2012 05:56 AM, Eric Dumazet wrote: >> On Tue, 2012-10-16 at 09:35 -0300, Ezequiel Garcia wrote: >> >>> Now, returning to the fragmentation. The problem with SLAB is that >>> its smaller cache available for kmalloced objects is 32 bytes; >>> while SLUB allows 8, 16, 24 ... >>> >>> Perhaps adding smaller caches to SLAB might make sense? >>> Is there any strong reason for NOT doing this? >> >> I would remove small kmalloc-XX caches, as sharing a cache line >> is sometime dangerous for performance, because of false sharing. >> >> They make sense only for very small hosts. > > That's interesting... > > It would be good to measure the performance/size tradeoff here. > I'm interested in very small systems, and it might be worth > the tradeoff, depending on how bad the performance is. Maybe > a new config option would be useful (I can hear the groans now... :-) > > Ezequiel - do you have any measurements of how much memory > is wasted by 32-byte kmalloc allocations for smaller objects, > in the tests you've been doing? Yes, we have some numbers: http://elinux.org/Kernel_dynamic_memory_analysis#Kmalloc_objects Are they too informal? I can add some details... They've been measured on a **very** minimal setup, almost every option is stripped out, except from initramfs, sysfs, and trace. On this scenario, strings allocated for file names and directories created by sysfs are quite noticeable, being 4-16 bytes, and produce a lot of fragmentation from that 32 byte cache at SLAB. Is an option to enable small caches on SLUB and SLAB worth it? Ezequiel -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>