From: Larry Finger <Larry.Finger@lwfinger.net>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Christoph Lameter <cl@linux-foundation.org>,
linux-kernel@vger.kernel.org, mel@csn.ul.ie
Subject: Re: [PATCH 2/2] SLUB: Disable debugging if it increases the minimum page order
Date: Thu, 11 Jun 2009 09:39:35 -0500 [thread overview]
Message-ID: <4A311727.40403@lwfinger.net> (raw)
In-Reply-To: <1244728824.17483.51.camel@penberg-laptop>
Pekka Enberg wrote:
> Hi Christoph,
>
> On Thu, 2009-06-11 at 09:43 -0400, Christoph Lameter wrote:
>> We have had that with SLAB. NO! This leads to the situation that some
>> slabs have debug on and some have not. You just do not know which.
>
> I do see your point but surely we don't want to use order 1 allocations
> in the fall-back case for kmalloc-4096? Couldn't we just add a printk
> saying that debug was disabled for the cache? After all, my patch is
> much better than what SLAB does.
>
> On Thu, 2009-06-11 at 09:43 -0400, Christoph Lameter wrote:
>> Note that CONFIG_SLUB_DEBUG only enables the code to debug a slab. It does
>> not enable debugging for each slab. CONFIG_SLUB_DEBUG_ON does that.
>
> True. Larry, do you have CONFIG_SLUB_DEBUG_ON enabled or are you passing
> SLUB debugging options to the kernel?
It is enabled in the kernel. My SLUB options in .config are:
finger@larrylap:~> grep SLUB .config
CONFIG_SLUB_DEBUG=y
CONFIG_SLUB=y
CONFIG_SLUB_DEBUG_ON=y
# CONFIG_SLUB_STATS is not set
Would having STATS enabled help?
For a bug that hits infrequently, determining that it is fixed is
difficult. That said, my system has been up about 22.5 hours during
which I have tried to force the failure. I see the fragmentation of
memory vary widely as shown below:
finger@larrylap:~> date ; cat /proc/buddyinfo
Wed Jun 10 20:15:34 CDT 2009
Node 0, zone DMA 4 3 5 2 4 1 2
0 1 0 0
Node 0, zone DMA32 5920 11678 2245 369 117 21 2
1 0 0 0
finger@larrylap:~> date ; cat /proc/buddyinfo
Wed Jun 10 23:32:39 CDT 2009
Node 0, zone DMA 4 3 5 2 4 1 2
0 1 0 0
Node 0, zone DMA32 2605 4140 3804 7 0 1 1
1 0 0 0
finger@larrylap:~> date ; cat /proc/buddyinfo
Thu Jun 11 09:28:06 CDT 2009
Node 0, zone DMA 4 3 5 2 4 1 2
0 1 0 0
Node 0, zone DMA32 2231 429 2726 54 1 0 1
1 0 0 0
finger@larrylap:~> cat /proc/uptime
80678.11 78.54
The latest value of the number of O(1) fragments is about as low as I
have seen.
Larry
prev parent reply other threads:[~2009-06-11 14:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-11 8:44 [PATCH 2/2] SLUB: Disable debugging if it increases the minimum page order Pekka J Enberg
2009-06-11 13:43 ` Christoph Lameter
2009-06-11 14:00 ` Pekka Enberg
2009-06-11 14:24 ` Christoph Lameter
2009-06-11 15:11 ` Pekka Enberg
2009-06-11 15:20 ` Christoph Lameter
2009-06-11 15:28 ` Pekka Enberg
2009-06-11 15:49 ` Christoph Lameter
2009-06-11 16:49 ` Larry Finger
2009-06-11 18:04 ` Mel Gorman
2009-06-11 18:26 ` Christoph Lameter
2009-06-11 19:16 ` Mel Gorman
2009-06-11 14:39 ` Larry Finger [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=4A311727.40403@lwfinger.net \
--to=larry.finger@lwfinger.net \
--cc=cl@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=penberg@cs.helsinki.fi \
/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.