From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Ajay Patel <patela@gmail.com>
Cc: linux-kernel@vger.kernel.org, cl@linux.com, penberg@kernel.org,
rientjes@google.com, iamjoonsoo.kim@lge.co, brouer@redhat.com,
linux-mm <linux-mm@kvack.org>
Subject: Re: 3.14.65: Memory leak when slub_debug is enabled
Date: Wed, 30 Mar 2016 10:58:44 +0200 [thread overview]
Message-ID: <20160330105844.4cf1f0b8@redhat.com> (raw)
In-Reply-To: <CAA4-JFLOmeYrWOEO_d2ALPgf0cWhC_fv1Gisz5fyH3uY1ogV1g@mail.gmail.com>
Hi Ajay,
Could you please provide info on kernel .config settings via commands:
grep HAVE_ALIGNED_STRUCT_PAGE .config
grep CONFIG_HAVE_CMPXCHG_DOUBLE .config
You can try to further debug your problem by defining SLUB_DEBUG_CMPXCHG
manually in mm/slub.c to get some verbose output on the cmpxchg failures.
Is the "Marvell Armada dual core ARMV7" a 32-bit CPU?
--Jesper
On Tue, 29 Mar 2016 15:32:26 -0700 Ajay Patel <patela@gmail.com> wrote:
> We have custom board with Marvell Armada dual core ARMV7.
> The driver uses buffers from kmalloc-8192 slab heavily.
> When slub_debug is enabled, the kmalloc-8192 active slabs are
> increasing. The slub stats shows cmpxchg_double_fail and objects_partial
> are increasing too. Eventually system panics on oom.
>
> Following patch fixes the issue.
> Has anybody encountered this issue?
> Is this right fix?
>
> I am not in mailing list please cc me.
>
> Thanks
> Ajay
>
>
> --- slub.c.orig Tue Mar 29 11:54:42 2016
> +++ slub.c Tue Mar 29 15:08:30 2016
> @@ -1562,9 +1562,12 @@
> void *freelist;
> unsigned long counters;
> struct page new;
> + int retry_count = 0;
> +#define RETRY_COUNT 10
>
> lockdep_assert_held(&n->list_lock);
>
> +again:
> /*
> * Zap the freelist and set the frozen bit.
> * The old freelist is the list of objects for the
> @@ -1587,8 +1590,13 @@
> if (!__cmpxchg_double_slab(s, page,
> freelist, counters,
> new.freelist, new.counters,
> - "acquire_slab"))
> + "acquire_slab")) {
> + if (retry_count++ < RETRY_COUNT) {
> + new.frozen = 0;
> + goto again;
> + }
> return NULL;
> + }
>
> remove_partial(n, page);
> WARN_ON(!freelist);
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
--
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:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Ajay Patel <patela@gmail.com>
Cc: linux-kernel@vger.kernel.org, cl@linux.com, penberg@kernel.org,
rientjes@google.com, iamjoonsoo.kim@lge.co, brouer@redhat.com,
linux-mm <linux-mm@kvack.org>
Subject: Re: 3.14.65: Memory leak when slub_debug is enabled
Date: Wed, 30 Mar 2016 10:58:44 +0200 [thread overview]
Message-ID: <20160330105844.4cf1f0b8@redhat.com> (raw)
In-Reply-To: <CAA4-JFLOmeYrWOEO_d2ALPgf0cWhC_fv1Gisz5fyH3uY1ogV1g@mail.gmail.com>
Hi Ajay,
Could you please provide info on kernel .config settings via commands:
grep HAVE_ALIGNED_STRUCT_PAGE .config
grep CONFIG_HAVE_CMPXCHG_DOUBLE .config
You can try to further debug your problem by defining SLUB_DEBUG_CMPXCHG
manually in mm/slub.c to get some verbose output on the cmpxchg failures.
Is the "Marvell Armada dual core ARMV7" a 32-bit CPU?
--Jesper
On Tue, 29 Mar 2016 15:32:26 -0700 Ajay Patel <patela@gmail.com> wrote:
> We have custom board with Marvell Armada dual core ARMV7.
> The driver uses buffers from kmalloc-8192 slab heavily.
> When slub_debug is enabled, the kmalloc-8192 active slabs are
> increasing. The slub stats shows cmpxchg_double_fail and objects_partial
> are increasing too. Eventually system panics on oom.
>
> Following patch fixes the issue.
> Has anybody encountered this issue?
> Is this right fix?
>
> I am not in mailing list please cc me.
>
> Thanks
> Ajay
>
>
> --- slub.c.orig Tue Mar 29 11:54:42 2016
> +++ slub.c Tue Mar 29 15:08:30 2016
> @@ -1562,9 +1562,12 @@
> void *freelist;
> unsigned long counters;
> struct page new;
> + int retry_count = 0;
> +#define RETRY_COUNT 10
>
> lockdep_assert_held(&n->list_lock);
>
> +again:
> /*
> * Zap the freelist and set the frozen bit.
> * The old freelist is the list of objects for the
> @@ -1587,8 +1590,13 @@
> if (!__cmpxchg_double_slab(s, page,
> freelist, counters,
> new.freelist, new.counters,
> - "acquire_slab"))
> + "acquire_slab")) {
> + if (retry_count++ < RETRY_COUNT) {
> + new.frozen = 0;
> + goto again;
> + }
> return NULL;
> + }
>
> remove_partial(n, page);
> WARN_ON(!freelist);
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2016-03-30 8:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAA4-JFLOmeYrWOEO_d2ALPgf0cWhC_fv1Gisz5fyH3uY1ogV1g@mail.gmail.com>
2016-03-29 23:35 ` 3.14.65: Memory leak when slub_debug is enabled Christoph Lameter
2016-03-30 8:58 ` Jesper Dangaard Brouer [this message]
2016-03-30 8:58 ` Jesper Dangaard Brouer
2016-03-30 20:50 ` Ajay Patel
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=20160330105844.4cf1f0b8@redhat.com \
--to=brouer@redhat.com \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.co \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=patela@gmail.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.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.