All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux.com>
To: Ajay Patel <patela@gmail.com>
Cc: linux-kernel@vger.kernel.org, penberg@kernel.org,
	brouer@redhat.com, rientjes@google.com, iamjoonsoo.kim@lge.co
Subject: Re: 3.14.65: Memory leak when slub_debug is enabled
Date: Tue, 29 Mar 2016 18:35:45 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.20.1603291829550.18069@east.gentwo.org> (raw)
In-Reply-To: <CAA4-JFLOmeYrWOEO_d2ALPgf0cWhC_fv1Gisz5fyH3uY1ogV1g@mail.gmail.com>

On Tue, 29 Mar 2016, Ajay Patel 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.

Hmmm... I thought we fall back to pass through to the page allocator for
order 1 requests? Why is it going through the regular allocator paths?

> Following patch fixes the issue.

Wonder how that could be? Does the __cmpxchg_double work correctly on ARM?

> Has anybody encountered this issue?
> Is this right fix?

Looks like something is screwing around with the page flags because an
order 1 page is a compound page? Can you ensure that order 1 allocs are
using page allocator fallback. See kmalloc_large().

       reply	other threads:[~2016-03-29 23:35 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 ` Christoph Lameter [this message]
2016-03-30  8:58 ` 3.14.65: Memory leak when slub_debug is enabled Jesper Dangaard Brouer
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=alpine.DEB.2.20.1603291829550.18069@east.gentwo.org \
    --to=cl@linux.com \
    --cc=brouer@redhat.com \
    --cc=iamjoonsoo.kim@lge.co \
    --cc=linux-kernel@vger.kernel.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.