From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753292AbdKXJyb (ORCPT ); Fri, 24 Nov 2017 04:54:31 -0500 Received: from mx2.suse.de ([195.135.220.15]:42001 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752387AbdKXJya (ORCPT ); Fri, 24 Nov 2017 04:54:30 -0500 Date: Fri, 24 Nov 2017 10:54:28 +0100 From: Michal Hocko To: Maninder Singh Cc: "kstewart@linuxfoundation.org" , "gregkh@linuxfoundation.org" , "jkosina@suse.cz" , "pombredanne@nexb.com" , "jpoimboe@redhat.com" , "akpm@linux-foundation.org" , "vbabka@suse.cz" , "guptap@codeaurora.org" , "vinmenon@codeaurora.org" , AMIT SAHRAWAT , PANKAJ MISHRA , Lalit Mohan Tripathi , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Vaneet Narang Subject: Re: [PATCH 1/1] stackdepot: interface to check entries and size of stackdepot. Message-ID: <20171124095428.5ojzgfd24sy7zvhe@dhcp22.suse.cz> References: <20171123162835.6prpgrz3qkdexx56@dhcp22.suse.cz> <1511347661-38083-1-git-send-email-maninder1.s@samsung.com> <20171124094108epcms5p396558828a365a876d61205b0fdb501fd@epcms5p3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171124094108epcms5p396558828a365a876d61205b0fdb501fd@epcms5p3> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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