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

[Vinayak Menon]

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