From: Manfred Spraul <manfred@colorfullife.com>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: "Martin J. Bligh" <mbligh@aracnet.com>,
Andrew Morton <akpm@osdl.org>,
linux-mm@kvack.org
Subject: Re: slab fragmentation ?
Date: Sun, 03 Oct 2004 08:04:59 +0200 [thread overview]
Message-ID: <415F968B.8000403@colorfullife.com> (raw)
In-Reply-To: <1096555693.12861.27.camel@dyn318077bld.beaverton.ibm.com>
Badari Pulavarty wrote:
>Yes. But the next allocations should be satisfied by filling in the
>partial slabs, instead of getting a new slab.
>
>As you can see from my tests, we are allocating and freeing few
>thousands every second. I can imagine this happening, if we allocated
>150K objects and then freed 140K of them randomly.
>
>
>
Could you check what is the maximum number of objects that were
allocated? Enable debugging and check /proc/slabinfo, it's listed in the
globalstat block.
>I modified "crash" kmem command to dump all the slabs in the cache.
>I am attaching the output.
>
>I am wondering why we are not filling up partial slabs, before
>allocating new ones ?
>
>
It should be impossible. s_show checks that the slabs are in the correct
list (full/partial/empty). You didn't get any errors, thus everything
was filed correctly. And cache_alloc_refill only calls cache_grow if the
partial and empty lists are empty.
Wait - do you use kmem_cache_alloc_node()? If you use this function then
the fragmentation you have described can easily happen.
--
Manfred
--
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/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2004-10-03 6:04 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-29 23:36 slab fragmentation ? Badari Pulavarty
2004-09-30 3:41 ` Andrew Morton
2004-09-30 4:52 ` badari
2004-09-30 14:49 ` Martin J. Bligh
2004-09-30 14:48 ` Badari Pulavarty
2004-10-03 6:04 ` Manfred Spraul [this message]
2004-10-04 15:51 ` Badari Pulavarty
2004-10-04 16:08 ` Manfred Spraul
2004-10-04 17:37 ` Badari Pulavarty
2004-10-05 14:46 ` Badari Pulavarty
2004-10-05 17:58 ` Manfred Spraul
2004-10-05 18:27 ` Badari Pulavarty
2004-10-05 18:49 ` Manfred Spraul
2004-10-05 18:47 ` Badari Pulavarty
2004-10-05 21:13 ` Badari Pulavarty
2004-10-05 22:11 ` Chen, Kenneth W
2004-10-05 22:18 ` Chen, Kenneth W
2004-10-06 14:58 ` Badari Pulavarty
2004-10-09 14:28 ` Manfred Spraul
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=415F968B.8000403@colorfullife.com \
--to=manfred@colorfullife.com \
--cc=akpm@osdl.org \
--cc=linux-mm@kvack.org \
--cc=mbligh@aracnet.com \
--cc=pbadari@us.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.