Slab allocator - questions

Slab allocator - questions

[Martin Maletinsky]

Hi,

I am currently studying the Slab allocator, and therefor studied the paper of Jeff Bonwick and the respective section in 'Understanding the Linux Kernel' by Bovet&Cesati.
Still I have the following questions:

1) What is the benefit of storing object descriptors (kmem_bufctl_t) and slab descriptors (kmem_slab_t) in the slab (for small objects) within the slab? Alternatively the
in-slab memory
occupied by those descriptors could be used to store additional objects in that slab, i.e. I don't see
that this saves any memory; however having two alternate places to store object & slab descriptors
increases the complexity of the implementation.

2) Why are there general caches up to a size of 128K byte? Since a slab consists of physically contiguous pages, one might call right into the buddy system to get chunks of
memory that are a
multiple of a page size. What is the benefit of allocating memory chunks that are a multiple of a page size by using kmalloc()/kmem_cache_alloc() rather than
get_free_pages?
[I am familiar with Intel and Alpha only, are there maybe architectures that have page sizes > 128K - this might be an explanation for having slab caches for memory chunks
up to 128 K]

3) How does the slab cache allocator deal with high memory pages in 2.4.x (i.e. pages for which no
KSEG address exists)? The comment at the beginning of slab.c states, that a cache can support memory of type GFP_HIGHMEM, however in kmem_cache_free_one() the
virt_to_page() macro is applied to the pointer to an object from the slab - however this macro only works for KSEG (logical) addresses. Why does the implementation still
behave correctly, even if it uses high memory (for which no KSEG addresses exist)?

Please put me on cc: in your reply, since I am not in the mailing lists.

thanks in advance for any help,
regards
Martin

--
Supercomputing System AG          email: maletinsky@scs.ch
Martin Maletinsky                 phone: +41 (0)1 445 16 05
Technoparkstrasse 1               fax:   +41 (0)1 445 16 10
CH-8005 Zurich


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

Re: Slab allocator - questions

[Benjamin LaHaise]

Hello,

On Wed, Apr 03, 2002 at 10:59:29AM +0200, Martin Maletinsky wrote:
...
> 2) Why are there general caches up to a size of 128K byte? Since a slab 
> consists of physically contiguous pages, one might call right into the 
> buddy system to get chunks of memory that are a multiple of a page size. 
> What is the benefit of allocating memory chunks that are a multiple of 
> a page size by using kmalloc()/kmem_cache_alloc() rather than
> get_free_pages?

Memory fragmentation.  By grouping objects of the same type and similar 
lifetimes, slab helps prevent the pinning of many individual pages across 
the system.  Since slab allocations cannot be relocated, this helps when 
other allocations need to obtain non-0 order pages.

> 3) How does the slab cache allocator deal with high memory pages in 2.4.x 
> (i.e. pages for which no KSEG address exists)?

They are not used.

		-ben
-- 
"A man with a bass just walked in,
 and he's putting it down
 on the floor."
--
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/

Re: Slab allocator - questions

[Martin Maletinsky]

Hello,

> ...
> > 2) Why are there general caches up to a size of 128K byte? Since a slab
> > consists of physically contiguous pages, one might call right into the
> > buddy system to get chunks of memory that are a multiple of a page size.
> > What is the benefit of allocating memory chunks that are a multiple of
> > a page size by using kmalloc()/kmem_cache_alloc() rather than
> > get_free_pages?
>
> Memory fragmentation.  By grouping objects of the same type and similar
> lifetimes, slab helps prevent the pinning of many individual pages across
> the system.  Since slab allocations cannot be relocated, this helps when
> other allocations need to obtain non-0 order pages.

Thank you for your reply. Could you detail how memory fragmentation is reduced? I understand the assumption that objects of the same type (and therefore same size) tend to
have similar lifetimes. However the general caches for objects that are a multiple of a page size contain one object per cache (see /proc/slabinfo). Each time such an
object is allocated by kmalloc(), the slab allocator will therefore use a new slab (which is allocated by calling into the buddy system). So what is the difference with
respect to memory fragmentation compared to calling straight the buddy system by using get_free_pages()?

regards
Martin
--
Supercomputing System AG          email: maletinsky@scs.ch
Martin Maletinsky                 phone: +41 (0)1 445 16 05
Technoparkstrasse 1               fax:   +41 (0)1 445 16 10
CH-8005 Zurich


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

Re: Slab allocator - questions

[Benjamin LaHaise]

On Thu, Apr 04, 2002 at 08:19:08AM +0200, Martin Maletinsky wrote:
> Thank you for your reply. Could you detail how memory fragmentation is 
> reduced? I understand the assumption that objects of the same type (and 
> therefore same size) tend to have similar lifetimes. However the general 
> caches for objects that are a multiple of a page size contain one object 
> per cache (see /proc/slabinfo). Each time such an object is allocated by 
> kmalloc(), the slab allocator will therefore use a new slab (which is 
> allocated by calling into the buddy system). So what is the difference 
> with > respect to memory fragmentation compared to calling straight the 
> buddy system by using get_free_pages()?

You're making assumptions about the page size of the system.  True, on 
most platforms it will result in the same effect as directly hitting the 
page allocator, but that is not always the case.  Think of ia64 with 
large page sizes (64KB and 256KB are supported by the hardware iirc).  In 
that case the slab will have an effect.

That said, the main reason for having the large slabs is backwards 
compatibility with kmalloc.

		-ben
-- 
"A man with a bass just walked in,
 and he's putting it down
 on the floor."
--
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/