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
