linux-kernel - Re: [Q] Default SLAB allocator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 16 Oct 2012 15:27:04 -0300
From:	Ezequiel Garcia <elezegarcia@...il.com>
To:	Tim Bird <tim.bird@...sony.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	David Rientjes <rientjes@...gle.com>,
	Andi Kleen <andi@...stfloor.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"celinux-dev@...ts.celinuxforum.org" 
	<celinux-dev@...ts.celinuxforum.org>
Subject: Re: [Q] Default SLAB allocator

On Tue, Oct 16, 2012 at 3:07 PM, Tim Bird <tim.bird@...sony.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/