All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: glittao@gmail.com, Yogesh Lal <ylal@codeaurora.org>
Cc: Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>
Subject: Re: [PATCH] mm/slub: use stackdepot to save stack trace in objects
Date: Tue, 13 Jul 2021 14:03:39 +0200	[thread overview]
Message-ID: <CAMuHMdW=eoVzM1Re5FVoEN87nKfiLmM2+Ah7eNu2KXEhCvbZyA@mail.gmail.com> (raw)
In-Reply-To: <20210414163434.4376-1-glittao@gmail.com>

Hi Oliver, Yogesh,

On Wed, Apr 14, 2021 at 8:08 PM <glittao@gmail.com> wrote:
> From: Oliver Glitta <glittao@gmail.com>
>
> Many stack traces are similar so there are many similar arrays.
> Stackdepot saves each unique stack only once.
>
> Replace field addrs in struct track with depot_stack_handle_t handle.
> Use stackdepot to save stack trace.
>
> The benefits are smaller memory overhead and possibility to aggregate
> per-cache statistics in the future using the stackdepot handle
> instead of matching stacks manually.
>
> Signed-off-by: Oliver Glitta <glittao@gmail.com>

Thanks for your patch, which is now commit 788691464c294553 ("mm/slub:
use stackdepot to save stack trace in objects") in v5.14-rc1.

> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1891,6 +1891,7 @@ config SLUB_DEBUG
>         default y
>         bool "Enable SLUB debugging support" if EXPERT
>         depends on SLUB && SYSFS
> +       select STACKDEPOT if STACKTRACE_SUPPORT
>         help
>           SLUB has extensive debug support features. Disabling these can
>           result in significant savings in code size. This also disables

This change increases memory consumption by 4 MiB (or more, see below).

Looking at lib/Kconfig:

|   config STACK_HASH_ORDER
|           int "stack depot hash size (12 => 4KB, 20 => 1024KB)"

The sizes reported here are not correct, as the actual memory consumption
is not STACK_HAS_ORDER bytes, but STACK_HAS_ORDER pointers.
Hence they're off by a factor of 4 or 8.

|           range 12 20
|           default 20

Does this really have to default to the maximum value?

|           depends on STACKDEPOT
|           help
|            Select the hash size as a power of 2 for the stackdepot hash table.
|            Choose a lower value to reduce the memory impact.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  parent reply	other threads:[~2021-07-13 12:03 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-14 16:34 [PATCH] mm/slub: use stackdepot to save stack trace in objects glittao
2021-04-20 16:58 ` Vlastimil Babka
2021-04-26  1:10 ` David Rientjes
2021-04-26  1:10   ` David Rientjes
2021-05-10  4:46 ` Andrew Morton
2021-05-12 14:33   ` Vlastimil Babka
2021-05-13  0:07     ` Andrew Morton
2021-05-16 19:51 ` [PATCH] mm/slub: use stackdepot to save stack trace in objects-fix Vlastimil Babka
2021-07-02 15:37 ` [PATCH] mm/slub: use stackdepot to save stack trace in objects Guenter Roeck
2021-07-02 16:01   ` Vlastimil Babka
2021-07-13 12:03 ` Geert Uytterhoeven [this message]
2021-07-13 12:03   ` Geert Uytterhoeven

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='CAMuHMdW=eoVzM1Re5FVoEN87nKfiLmM2+Ah7eNu2KXEhCvbZyA@mail.gmail.com' \
    --to=geert@linux-m68k.org \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=glittao@gmail.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=vbabka@suse.cz \
    --cc=ylal@codeaurora.org \
    /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.