Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 4 Jan 2021 15:12:23 -0800
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
Message-Id: <20210104151223.34f97a033e966c9cc89915cb@linux-foundation.org>
In-Reply-To: <1609332331-2456-1-git-send-email-vjitta@codeaurora.org>
References: <1609332331-2456-1-git-send-email-vjitta@codeaurora.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

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?