From: "Catalin Marinas" <catalin.marinas@gmail.com>
To: "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.18-rc6 00/10] Kernel memory leak detector 0.10
Date: Thu, 7 Sep 2006 10:10:51 +0100 [thread overview]
Message-ID: <b0943d9e0609070210p661a2cd6k5683d0956aaab5fe@mail.gmail.com> (raw)
In-Reply-To: <6bffcb0e0609070205i27c19d3cq9fa0fc6961f28fa3@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 810 bytes --]
On 07/09/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> On 07/09/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> > On 07/09/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > > On 07/09/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> > > > On 07/09/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > > > > CONFIG_DEBUG_MEMLEAK=y
> > > > > CONFIG_DEBUG_MEMLEAK_HASH_BITS=8
> >
> > Have you tried 16?
>
> No, I haven't.
8 hash bits would lead to a really slow hash table lookup since you
would only have 256 entries and it uses linked lists to deal with
collisions (you may have tens of thousands of pointers to be stored in
the hash). Anyway, I attach a patch which allows you to set small
values but it is highly unrecommended.
--
Catalin
[-- Attachment #2: hash-bits-fix.patch --]
[-- Type: text/x-patch, Size: 1112 bytes --]
Allow small values of HASH_BITS to be configured
From: Catalin Marinas <catalin.marinas@arm.com>
The original implementation was assuming that the HASH_BITS value is small
big enough so that the page order is at least 0. This patch corrects this.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
mm/memleak.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/mm/memleak.c b/mm/memleak.c
index 0b5aa0c..a65d930 100644
--- a/mm/memleak.c
+++ b/mm/memleak.c
@@ -180,12 +180,15 @@ #define OBJECT_TYPE_GUESSED 0x2
/* Hash functions */
static void hash_init(void)
{
- int i;
- int hash_size = sizeof(*pointer_hash) * (1 << HASH_BITS);
- int hash_order = fls(hash_size) - 1;
+ unsigned int i;
+ unsigned int hash_size = sizeof(*pointer_hash) * (1 << HASH_BITS);
+ unsigned int hash_order = fls(hash_size) - 1;
+ /* hash_size not a power of 2 */
if (hash_size & ((1 << hash_order) - 1))
hash_order += 1;
+ if (hash_order < PAGE_SHIFT)
+ hash_order = PAGE_SHIFT;
pointer_hash = (struct hlist_head *)
__get_free_pages(GFP_ATOMIC, hash_order - PAGE_SHIFT);
next prev parent reply other threads:[~2006-09-07 9:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-06 22:35 Catalin Marinas
2006-09-06 22:36 ` [PATCH 2.6.18-rc6 01/10] Base support for kmemleak Catalin Marinas
2006-09-06 22:36 ` [PATCH 2.6.18-rc6 02/10] Some documentation " Catalin Marinas
2006-09-06 22:36 ` [PATCH 2.6.18-rc6 03/10] Add the memory allocation/freeing hooks " Catalin Marinas
2006-09-06 22:36 ` [PATCH 2.6.18-rc6 04/10] Modules support " Catalin Marinas
2006-09-06 22:37 ` [PATCH 2.6.18-rc6 05/10] Add kmemleak support for i386 Catalin Marinas
2006-09-06 22:37 ` [PATCH 2.6.18-rc6 06/10] Add kmemleak support for ARM Catalin Marinas
2006-09-06 22:37 ` [PATCH 2.6.18-rc6 07/10] Remove some of the kmemleak false positives Catalin Marinas
2006-09-06 22:37 ` [PATCH 2.6.18-rc6 08/10] Keep the __init functions after initialization Catalin Marinas
2006-09-06 22:37 ` [PATCH 2.6.18-rc6 09/10] Simple testing for kmemleak Catalin Marinas
2006-09-06 22:37 ` [PATCH 2.6.18-rc6 10/10] Update the MAINTAINERS file " Catalin Marinas
2006-09-07 0:10 ` [PATCH 2.6.18-rc6 00/10] Kernel memory leak detector 0.10 Michal Piotrowski
2006-09-07 8:04 ` Catalin Marinas
2006-09-07 8:35 ` Michal Piotrowski
2006-09-07 8:37 ` Catalin Marinas
2006-09-07 8:40 ` Michal Piotrowski
2006-09-07 8:52 ` Catalin Marinas
2006-09-07 9:05 ` Michal Piotrowski
2006-09-07 9:10 ` Catalin Marinas [this message]
2006-09-07 9:35 ` Michal Piotrowski
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=b0943d9e0609070210p661a2cd6k5683d0956aaab5fe@mail.gmail.com \
--to=catalin.marinas@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.k.k.piotrowski@gmail.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
all inboxes | Powered by JetHome®