linux-kernel - Re: Kmem_cache handling in linux-2.6.2x kernel

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:	Wed, 9 Jul 2008 13:42:12 +0300
From:	"Pekka Enberg" <penberg@...helsinki.fi>
To:	KokHow.Teh@...ineon.com
Cc:	linux-kernel@...r.kernel.org, cl@...ux-foundation.org
Subject: Re: Kmem_cache handling in linux-2.6.2x kernel

Hi,

On Wed, Jul 9, 2008 at 1:30 PM,  <KokHow.Teh@...ineon.com> wrote:
> In my applications, only part of total number of objects of the
> kmem_cache are freed. So my question is what happen to these "freed"
> objects? How are these "freed" objects managed by the linux-MM? Would
> they be reused by other kmem_cache_alloc() and/or kmalloc()?

The free'd objects will be returned to the cache and are, of course,
reused by later kmem_cache_alloc() and kmalloc() calls. Note that with
_SLAB_, you never have cache sharing, so an object free'd by
kmem_cache_free() is only available for a kmem_cache_alloc() of the
same cache.

At some point in time, I wrote:
>>In addition, SLUB does slab merging so the same cache can be
>> transparently used by other kmem_cache_alloc() callers. So there really
>> are no reservation guarantees for a cache in OOM conditions.

On Wed, Jul 9, 2008 at 1:30 PM,  <KokHow.Teh@...ineon.com> wrote:
> (1) SLUB is not available in 2.6.20 kernel which I am using for my
> products. In this case, is there similar mechamisms in place to
> faciliate "page-sharing" amongst the kmem_cache_alloc() callers?

No.

On Wed, Jul 9, 2008 at 1:30 PM,  <KokHow.Teh@...ineon.com> wrote:
> (2) Does this "page-sharing" happen for kmalloc() callers?

The caches for kmalloc() are set up first, so a kmalloc() never dips
into a cache created by kmem_cache_create(). But a kmem_cache_alloc()
can dip into a kmalloc cache. Look at the create_kmalloc_cache() calls
in kmem_cache_init() and the find_mergeable() call in
kmem_cache_create() in mm/slub.c for details.

Btw, you mentioned that you're allocating 64 KBs. So with SLUB, if you
use _kmalloc()_ the request will be passed through to the page
allocator directly (see kmalloc_large()).
--
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/