Messages in this thread | | | Date | Mon, 4 Jan 2021 15:12:23 -0800 | From | Andrew Morton <> | Subject | Re: [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?
| |