From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx181.postini.com [74.125.245.181]) by kanga.kvack.org (Postfix) with SMTP id D779A6B0062 for ; Tue, 16 Oct 2012 14:27:04 -0400 (EDT) Received: by mail-ie0-f169.google.com with SMTP id 10so12866896ied.14 for ; Tue, 16 Oct 2012 11:27:04 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <507DA245.9050709@am.sony.com> References: <1350392160.3954.986.camel@edumazet-glaptop> <507DA245.9050709@am.sony.com> Date: Tue, 16 Oct 2012 15:27:04 -0300 Message-ID: Subject: Re: [Q] Default SLAB allocator From: Ezequiel Garcia Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Tim Bird Cc: Eric Dumazet , David Rientjes , Andi Kleen , Linux Kernel Mailing List , "linux-mm@kvack.org" , "celinux-dev@lists.celinuxforum.org" On Tue, Oct 16, 2012 at 3:07 PM, Tim Bird 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@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org