All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: vjitta@codeaurora.org
Cc: minchan@kernel.org, glider@google.com, dan.j.williams@intel.com,
	broonie@kernel.org, mhiramat@kernel.org,
	linux-kernel@vger.kernel.org, ylal@codeaurora.org,
	vinmenon@codeaurora.org, Thomas Gleixner <tglx@linutronix.de>,
	Alexander Potapenko <glider@google.com>
Subject: Re: [PATCH v4 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE
Date: Mon, 4 Jan 2021 15:12:23 -0800	[thread overview]
Message-ID: <20210104151223.34f97a033e966c9cc89915cb@linux-foundation.org> (raw)
In-Reply-To: <1609332331-2456-1-git-send-email-vjitta@codeaurora.org>

On Wed, 30 Dec 2020 18:15:30 +0530 vjitta@codeaurora.org wrote:

> Use STACK_HASH_ORDER_SHIFT to configure STACK_HASH_SIZE.
> 
> Aim is to have configurable value for  STACK_HASH_SIZE,
> so depend on use case one can configure it.
> 
> One example is of Page Owner, default value of
> STACK_HASH_SIZE lead stack depot to consume 8MB of static memory.
> Making it configurable and use lower value helps to enable features like
> CONFIG_PAGE_OWNER without any significant overhead.

Questions regarding the stackdepot code.

- stack_table_tmp[] is __initdata.  So after initmem is released,
  that "consume 8MB of static memory" should no longer be true.  But
  iirc, not all architectures actually release __initdata memory.  Does
  your architecture do this?

- Stackdepot copies stack_table_tmp[] into vmalloced memory during
  initcalls.  Why?  Why not simply make stack_table_tmp[] no longer
  __initdata and use that memory for all time?

  Presumably because in the stack_depot_disable==true case, we
  release stack_table_tmp[] memory, don't vmalloc for a copy of it, and
  save a bunch of memory?  If so, this assumes that the __initdata
  memory is freed.

- Why is that hash table so large?  Is it appropriately sized?

- SMP is up and running during init_stackdepot(), I think?  If so, is
  that huge memcpy smp-safe?  Can other CPUs be modifying
  stack_table_tmp[] while the memcpy is in flight?




  parent reply	other threads:[~2021-01-04 23:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-30 12:45 [PATCH v4 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE vjitta
2020-12-30 12:45 ` [PATCH v4 2/2] lib: stackdepot: Add support to disable stack depot vjitta
2021-01-04 23:12 ` Andrew Morton [this message]
2021-01-05  9:24   ` [PATCH v4 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE Vijayanand Jitta
2021-01-19  4:02     ` Vijayanand Jitta
2021-01-07  9:44 ` Alexander Potapenko
2021-01-18 11:14   ` Vijayanand Jitta

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=20210104151223.34f97a033e966c9cc89915cb@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=broonie@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=glider@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=minchan@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=vinmenon@codeaurora.org \
    --cc=vjitta@codeaurora.org \
    --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.