From: Benjamin LaHaise <bcrl@redhat.com>
To: Martin Maletinsky <maletinsky@scs.ch>
Cc: kernelnewbies@nl.linux.org, linux-mm@kvack.org
Subject: Re: Slab allocator - questions
Date: Thu, 4 Apr 2002 17:30:16 -0500 [thread overview]
Message-ID: <20020404173016.C24914@redhat.com> (raw)
In-Reply-To: <3CABF05C.4EA66796@scs.ch>; from maletinsky@scs.ch on Thu, Apr 04, 2002 at 08:19:08AM +0200
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/
prev parent reply other threads:[~2002-04-04 22:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-03 8:59 Martin Maletinsky
2002-04-03 19:32 ` Benjamin LaHaise
2002-04-04 6:19 ` Martin Maletinsky
2002-04-04 22:30 ` Benjamin LaHaise [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020404173016.C24914@redhat.com \
--to=bcrl@redhat.com \
--cc=kernelnewbies@nl.linux.org \
--cc=linux-mm@kvack.org \
--cc=maletinsky@scs.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox