Re: [PATCH 1/1] stackdepot: interface to check entries and size of stackdepot.

[Vinayak Menon <vinmenon@codeaurora.org>]

On 11/24/2017 7:00 PM, Vaneet Narang wrote:
> Hi Michal,
>
>>>  We have been getting similar kind of such entries and eventually
>>>  stackdepot reaches Max Cap. So we found this interface useful in debugging
>>>  stackdepot issue so shared in community.
>  
>> Then use it for internal debugging and provide a code which would scale
>> better on smaller systems. We do not need this in the kernel IMHO. We do
>> not merge all the debugging patches we use for internal development.
> ` 
> Not just debugging but this information can also be used to profile and tune stack depot. 
> Getting count of stack entries would help in deciding hash table size and 
> page order used by stackdepot. 
>
> For less entries, bigger hash table and higher page order slabs might not be required as 
> maintained by stackdepot. As i already mentioned smaller size hashtable can be choosen and 
> similarly lower order  pages can be used for slabs.
>
> If you think its useful, we can share scalable patch to configure below two values based on 
> number of stack entries dynamically.
>
> #define STACK_ALLOC_ORDER 2 
> #define STACK_HASH_SIZE (1L << STACK_HASH_ORDER)
It will be good if this hash table size can be tuned somehow. When CONFIG_PAGE_OWNER is enabled, we expect it to
consume significant amount of memory only when "page_owner" kernel param is set. But since PAGE_OWNER selects
STACKDEPOT, it consumes around 8MB (stack_table) on 64 bit without even a single stack being stored. This is a problem
on low RAM targets where we want to keep CONFIG_PAGE_OWNER enabled by default and for debugging enable the
feature via the kernel param.
I am not sure how feasible it is to configure it dynamically, but I think a hash_size early param and then a memblock alloc
of stack table at boot would work and help low ram devices.

Thanks,
Vinayak