linux-kernel - Re: [PATCH 2/3]: xvmalloc memory 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]

Message-ID: <49BFE415.8020803@vflare.org>
Date:	Tue, 17 Mar 2009 23:25:33 +0530
From:	Nitin Gupta <nitingupta910@...il.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3]: xvmalloc memory allocator

(sending again since it was blocked by lkml last time. Sorry Christoph for duplicate email).

Christoph Lameter wrote:
> On Tue, 17 Mar 2009, Nitin Gupta wrote:
> 
>> Slub allocator could not be used due to fragmentation issues:
>> http://code.google.com/p/compcache/wiki/AllocatorsComparison
>> Data here shows kmalloc using ~43% more memory than TLSF and xvMalloc
>> is showed ~2% more space efficiency than TLSF (due to smaller metadata).
> 
> Well this looks like the use of 2^n sizes of the kmalloc arrayse cause a
> lot of wastage here. Creating slab caches that fit your needs may help?

Creating slabs for sizes in range, say, [32, 3/4*PAGE_SIZE] separated by 64bytes
will require 48 slabs! Then for slab of each size class will have wastage due to
unused slab objects in each class.
Larger difference in slab sizes (and thus small no. of them), will surely cause too much
wastage due to internal fragmentation.

Another (more important) point to consider is that, use of slabs will eat-up vmalloc
area to keep slab memory backed by VA space. On 32-bit systems, vmalloc area
is small and limits amount of memory that can be allocated for compressed pages.
With xvmalloc we map/unmap pages on demand thus removing dependence on
vmalloc VA area.

 > Have you had a look at the SLOB approach?
 >

Nope. I will see how this may help.

Thanks,
Nitin

--
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/