lkml.org 
[lkml]   [2017]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 1/1] stackdepot: interface to check entries and size of stackdepot.
    On Fri, Nov 24, 2017 at 10:54 AM, Michal Hocko <mhocko@kernel.org> wrote:
    > On Fri 24-11-17 09:41:08, Maninder Singh wrote:
    >> 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)
    >
    > OK, so debugging a debugging facility... I do not think we want to
    > introduce a lot of code for something like that.
    >
    >> 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.
    >
    > What are you going to do with that information. It is not like you can
    > reduce the memory footprint or somehow optimize anything during the
    > runtime.
    >
    > --
    > Michal Hocko
    > SUSE Labs

    +kasan-dev mailing list

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