Hi Michal,
> On Wed 22-11-17 16:17:41, Maninder Singh wrote:
> > This patch provides interface to check all the stack enteries
> > saved in stackdepot so far as well as memory consumed by stackdepot.
> >
> > 1) Take current depot_index and offset to calculate end address for one
> > iteration of (/sys/kernel/debug/depot_stack/depot_entries).
> >
> > 2) Fill end marker in every slab to point its end, and then use it while
> > traversing all the slabs of stackdepot.
> >
> > "debugfs code inspired from page_onwer's way of printing BT"
> >
> > checked on ARM and x86_64.
> > $cat /sys/kernel/debug/depot_stack/depot_size
> > Memory consumed by Stackdepot:208 KB
> >
> > $ cat /sys/kernel/debug/depot_stack/depot_entries
> > stack count 1 backtrace
> > init_page_owner+0x1e/0x210
> > start_kernel+0x310/0x3cd
> > secondary_startup_64+0xa5/0xb0
> > 0xffffffffffffffff
>
> Why do we need this? Who is goging to use this information and what for?
> I haven't looked at the code but just the diffstat looks like this
> should better have a _very_ good justification to be considered for
> merging. To be honest with you I have hard time imagine how this can be
> useful other than debugging stack depot...
This interface can be used for multiple reasons as:
1) For debugging stackdepot for sure.
2) For checking all the unique allocation paths in system.
3) To check if any invalid stack is coming which is increasing
stackdepot memory.
(https://lkml.org/lkml/2017/10/11/353)
Althoutgh this needs to be taken care in ARM as replied by maintainer, but with help
of this interface it was quite easy to check and we added workaround for saving memory.
4) At some point of time to check current memory consumed by stackdepot.
5) To check number of entries in stackdepot to decide stackdepot hash size for different systems.
For fewer entries hash table size can be reduced from 4MB.
Thanks
Maninder Singh
From 1584874989254914530@xxx Thu Nov 23 16:29:31 +0000 2017
X-GM-THRID: 1584763196629983480
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread