From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753682AbdK1Dh5 (ORCPT ); Mon, 27 Nov 2017 22:37:57 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:47600 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752277AbdK1Dhz (ORCPT ); Mon, 27 Nov 2017 22:37:55 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org DAEB068D18 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=vinmenon@codeaurora.org Subject: Re: [PATCH 1/1] stackdepot: interface to check entries and size of stackdepot. To: v.narang@samsung.com, Michal Hocko Cc: Dmitry Vyukov , Maninder Singh , "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" , AMIT SAHRAWAT , PANKAJ MISHRA , Lalit Mohan Tripathi , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , kasan-dev References: <20171124124429.juonhyw4xbqc65u7@dhcp22.suse.cz> <20171123162835.6prpgrz3qkdexx56@dhcp22.suse.cz> <1511347661-38083-1-git-send-email-maninder1.s@samsung.com> <20171124094108epcms5p396558828a365a876d61205b0fdb501fd@epcms5p3> <20171124095428.5ojzgfd24sy7zvhe@dhcp22.suse.cz> <20171124115707epcms5p4fa19970a325e87f08eadb1b1dc6f0701@epcms5p4> <20171124133025epcms5p7dc263c4a831552245e60193917a45b07@epcms5p7> From: Vinayak Menon Message-ID: Date: Tue, 28 Nov 2017 09:07:46 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171124133025epcms5p7dc263c4a831552245e60193917a45b07@epcms5p7> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > #define STACK_ALLOC_ORDER 2 > #define STACK_HASH_SIZE (1L << STACK_HASH_ORDER) 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. Thanks, Vinayak