From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Andrew Morton <akpm@osdl.org>, Badari Pulavarty <pbadari@us.ibm.com>
Cc: manfred@colorfullife.com, linux-mm@kvack.org
Subject: Re: slab fragmentation ?
Date: Thu, 30 Sep 2004 07:49:56 -0700 [thread overview]
Message-ID: <29460000.1096555795@[10.10.2.4]> (raw)
In-Reply-To: <20040929204143.134154bc.akpm@osdl.org>
--Andrew Morton <akpm@osdl.org> wrote (on Wednesday, September 29, 2004 20:41:43 -0700):
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
>>
>> # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <batchcount> <limit> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
>> size-40 2633 11468 64 61 1 : tunables 120 60 8 : slabdata 188 188 0
>> size-40 2633 11468 64 61 1 : tunables 120 60 8 : slabdata 188 188 0
>> size-40 2633 11468 64 61 1 : tunables 120 60 8 : slabdata 188 188 0
>> size-40 2633 11468 64 61 1 : tunables 120 60 8 : slabdata 188 188 0
>> size-40 4457 27084 64 61 1 : tunables 120 60 8 : slabdata 444 444 0
>> size-40 7685 59292 64 61 1 : tunables 120 60 8 : slabdata 972 972 0
>> size-40 10761 89548 64 61 1 : tunables 120 60 8 : slabdata 1468 1468 0
>> size-40 13589 119316 64 61 1 : tunables 120 60 8 : slabdata 1956 1956 0
>> size-40 16717 149084 64 61 1 : tunables 120 60 8 : slabdata 2444 2444 0
>
> That looks like plain brokenness rather than fragmentation. We shouldn't
> be allocating new pages until active_objs reaches num_objs, should we?
>
> Unless the accouting is broken, or course...
Doesn't this happen if we allocate 1000 slabs, then free half the elements
in each of the slabs? Which seemed to be the default action of the slab
shrink routines ;-)
M.
--
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-09-30 14:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-29 23:36 Badari Pulavarty
2004-09-30 3:41 ` Andrew Morton
2004-09-30 4:52 ` badari
2004-09-30 14:49 ` Martin J. Bligh [this message]
2004-09-30 14:48 ` Badari Pulavarty
2004-10-03 6:04 ` Manfred Spraul
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='29460000.1096555795@[10.10.2.4]' \
--to=mbligh@aracnet.com \
--cc=akpm@osdl.org \
--cc=linux-mm@kvack.org \
--cc=manfred@colorfullife.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox