[lkml]   [2017]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/1] stackdepot: interface to check entries and size of stackdepot.
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.
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.


 \ /
  Last update: 2017-11-28 04:40    [W:0.044 / U:3.880 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site