On Wed, 30 Dec 2020 18:15:30 +0530 vji...@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?
