On Fri, Nov 24, 2017 at 10:54 AM, Michal Hocko <mhocko@xxxxxxxxxx> 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
