lkml.org 
[lkml]   [2021]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE
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?



\
 
 \ /
  Last update: 2021-01-05 00:14    [W:0.153 / U:0.960 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site