Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932118Ab2JPS1H (ORCPT ); Tue, 16 Oct 2012 14:27:07 -0400 Received: from mail-ia0-f174.google.com ([209.85.210.174]:58364 "EHLO mail-ia0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755758Ab2JPS1E (ORCPT ); Tue, 16 Oct 2012 14:27:04 -0400 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 To: Tim Bird Cc: Eric Dumazet , David Rientjes , Andi Kleen , Linux Kernel Mailing List , "linux-mm@kvack.org" , "celinux-dev@lists.celinuxforum.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1901 Lines: 49 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 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/