From: Yogesh Lal <[email protected]>
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.
Signed-off-by: Yogesh Lal <[email protected]>
Signed-off-by: Vinayak Menon <[email protected]>
Signed-off-by: Vijayanand Jitta <[email protected]>
---
lib/Kconfig | 9 +++++++++
lib/stackdepot.c | 3 +--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/lib/Kconfig b/lib/Kconfig
index 3321d04..fd967fb 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -623,6 +623,15 @@ config STACKDEPOT
bool
select STACKTRACE
+config STACK_HASH_ORDER_SHIFT
+ int "stack depot hash size (12 => 4KB, 20 => 1024KB)"
+ range 12 20
+ default 20
+ depends on STACKDEPOT
+ help
+ Select the hash size as a power of 2 for the stackdepot hash table.
+ Choose a lower value to reduce the memory impact.
+
config SBITMAP
bool
diff --git a/lib/stackdepot.c b/lib/stackdepot.c
index 81c69c0..614ac28 100644
--- a/lib/stackdepot.c
+++ b/lib/stackdepot.c
@@ -141,8 +141,7 @@ static struct stack_record *depot_alloc_stack(unsigned long *entries, int size,
return stack;
}
-#define STACK_HASH_ORDER 20
-#define STACK_HASH_SIZE (1L << STACK_HASH_ORDER)
+#define STACK_HASH_SIZE (1L << CONFIG_STACK_HASH_ORDER_SHIFT)
#define STACK_HASH_MASK (STACK_HASH_SIZE - 1)
#define STACK_HASH_SEED 0x9747b28c
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
2.7.4
On Wed, 30 Dec 2020 18:15:30 +0530 [email protected] 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?
On 1/5/2021 4:42 AM, Andrew Morton wrote:
> On Wed, 30 Dec 2020 18:15:30 +0530 [email protected] 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?
>
Thanks for review comments, I wasn't aware that __initdata is
architecture dependent, I was assuming that __initdata always frees
memory and yes the architecture which i am using (arm64) does free
__inidata.
> - 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.
>
Yes, that correct. assumption here is __initidata will free memory if
stack_depot_disable=true is set.
> - Why is that hash table so large? Is it appropriately sized?
>
I think the large size of hash table is justified since the users of
stack depot like kasan, page owner etc store a very large number of stacks.
> - 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?
>
>
>
Yes, parallel access could be possible. I will add a locking mechanism
inplace.
Thanks,
Vijay
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation
On Wed, Dec 30, 2020 at 1:46 PM <[email protected]> wrote:
>
> From: Yogesh Lal <[email protected]>
>
> Use STACK_HASH_ORDER_SHIFT to configure STACK_HASH_SIZE.
I think "ORDER_SHIFT" is somewhat redundant, as "SMTH_ORDER" already
means this is a power of two we'll be using for shifting.
Leaving this up to you.
Alex
On 1/7/2021 3:14 PM, Alexander Potapenko wrote:
> On Wed, Dec 30, 2020 at 1:46 PM <[email protected]> wrote:
>>
>> From: Yogesh Lal <[email protected]>
>>
>> Use STACK_HASH_ORDER_SHIFT to configure STACK_HASH_SIZE.
> I think "ORDER_SHIFT" is somewhat redundant, as "SMTH_ORDER" already
> means this is a power of two we'll be using for shifting.
> Leaving this up to you.
>
> Alex
>
Right, updated this to STACK_HASH_ORDER in v5.
https://lkml.org/lkml/2021/1/18/255
Thanks,
Vijay
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation
On 1/5/2021 2:54 PM, Vijayanand Jitta wrote:
>
>
> On 1/5/2021 4:42 AM, Andrew Morton wrote:
>> On Wed, 30 Dec 2020 18:15:30 +0530 [email protected] 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?
>>
> Thanks for review comments, I wasn't aware that __initdata is
> architecture dependent, I was assuming that __initdata always frees
> memory and yes the architecture which i am using (arm64) does free
> __inidata.
>
>> - 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.
>>
>
> Yes, that correct. assumption here is __initidata will free memory if
> stack_depot_disable=true is set.
>
>> - Why is that hash table so large? Is it appropriately sized?
>>
>
> I think the large size of hash table is justified since the users of
> stack depot like kasan, page owner etc store a very large number of stacks.
>
>> - 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?
>>
>>
>>
> Yes, parallel access could be possible. I will add a locking mechanism
> inplace.
>
> Thanks,
> Vijay
>
I have updated the patch avoiding __initdata as per suggestion and the
copy from tmp , can you please review v5.
https://lore.kernel.org/patchwork/patch/1367306/
Thanks,
Vijay
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation