From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752988AbdKXMeU (ORCPT ); Fri, 24 Nov 2017 07:34:20 -0500 Received: from mailout1.samsung.com ([203.254.224.24]:34322 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751505AbdKXMeS (ORCPT ); Fri, 24 Nov 2017 07:34:18 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.samsung.com 20171124123416epoutp019c65fb2d1a9de499db4bf6aa10a2b648~6BarSzjyB2821628216epoutp01P X-AuditID: b6c32a4a-b79ff70000001151-0a-5a1811c7a5a2 Mime-Version: 1.0 Subject: RE: Re: [PATCH 1/1] stackdepot: interface to check entries and size of stackdepot. Reply-To: v.narang@samsung.com From: Vaneet Narang To: Dmitry Vyukov , Michal Hocko CC: 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" , "vinmenon@codeaurora.org" , AMIT SAHRAWAT , PANKAJ MISHRA , Lalit Mohan Tripathi , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , kasan-dev X-Priority: 3 X-Content-Kind-Code: NORMAL In-Reply-To: X-Drm-Type: Y,confirm X-EPWebmail-Msg-Type: personal X-Msg-Generator: Mail X-Msg-Type: PERSONAL X-Reply-Demand: N Message-ID: <20171124115707epcms5p4fa19970a325e87f08eadb1b1dc6f0701@epcms5p4> Date: Fri, 24 Nov 2017 11:57:07 +0000 X-CMS-MailID: 20171124115707epcms5p4fa19970a325e87f08eadb1b1dc6f0701 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Sendblock-Type: REQ_APPROVE X-MTR: 20171124115707epcms5p4fa19970a325e87f08eadb1b1dc6f0701 CMS-TYPE: 105P X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGJsWRmVeSWpSXmKPExsWy7bCmhu5xQYkog1kHVS0u7k61mLN+DZvF hIdt7BbNi9ezWXx7uILNYvecxSwWB36eYLRY8ew+k0XPnCZGi/7FZhaXd81hs7i35j+rxeH5 bSwWr78tY7a492Yrk8X/3+dYLWY39jFarN96gN1ByONyXy+Tx4JNpR57Jp5k89i0qhNIfJrE 7nFixm8Wj/1z17B7LN9p4vF+31U2j74tqxg9ziw4wu7xeZNcAE9Uqk1GamJKapFCal5yfkpm XrqtkndwvHO8qZmBoa6hpYW5kkJeYm6qrZKLT4CuW2YO0HNKCmWJOaVAoYDE4mIlfTubovzS klSFjPziElulaENDIz1DA3M9IyMjPRPTWCsjU6CShNSMube3MBbcEapYMGMSYwPjWv4uRk4O CQETiaWHjrF3MXJxCAnsZpS41b6ItYuRg4NXQFDi7w5hEFNYIFbixvp4kHIhATmJ4zd2M4LY wgI6EifmrWEEKWET0JL42BIOEhYR8JA4/OABI8hEZoF+Nomtn1+xQKzilZjR/hTKlpbYvnwr 2BxOgUCJK5e7mSHiohJ/GmBq5CSmfV0DF39/bD4jhC0i0XrvLFRcUOLBz91QcRmJ71/7WUEW Swh0M0rcf/uVBcKZwiixaN4/qKnmEudPzgfr5hXwlbh98xcTiM0ioCrx7dtyNpBvJARcJBp+ ZYKEmQXkJba/ncMMEmYW0JRYv0sfYoqsxNRT65ggbFuJNT8mMkOU80n0/n7CBPPvjnkwtpLE uYM72SBsCYknnTOZJzAqz0IE9Cwky2YhLFvAyLyKUTK1oDg3PbXYtMAoL7Vcrzgxt7g0L10v OT93EyM4jWt57WBcds7nEKMAB6MSD2/BI7EoIdbEsuLK3EOMEhzMSiK88k+BQrwpiZVVqUX5 8UWlOanFhxhNgb6eyCwlmpwPzDF5JfGGJpYGJmZm5oYGBpYmSuK8x3aWRgoJpCeWpGanphak FsH0MXFwSjUwynWtXf96QVRDd/aP0HObL7D6M3Wzy/gLvo242Fhvfrnzd+ctY+eX1t33onk8 OFZO3P4quCkgcMaEfwmfFygVXd9etU7/cmNlwWKp5yY6npnygZXn97LZdfyscZx9Nbpz0prF fWozopI8bwoE533YP+XN5EWzLsd9WGMpf3b2pk/+MilTi4uNlFiKMxINtZiLihMBAIV9CvkD AAA= DLP-Filter: Pass X-CFilter-Loop: Reflected X-CMS-RootMailID: 20171122105142epcas5p173b7205da12e1fc72e16ec74c49db665 X-RootMTR: 20171122105142epcas5p173b7205da12e1fc72e16ec74c49db665 References: <20171123162835.6prpgrz3qkdexx56@dhcp22.suse.cz> <1511347661-38083-1-git-send-email-maninder1.s@samsung.com> <20171124094108epcms5p396558828a365a876d61205b0fdb501fd@epcms5p3> <20171124095428.5ojzgfd24sy7zvhe@dhcp22.suse.cz> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Michal, >> 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. On low memory system where page owner entries are in range of 3k ~ 4k, its a waste to keep hash table size of 4MB. It can be modified to some 128KB to save memory footprint of stackdepot. So stackdepot entry count is important. > OK, so debugging a debugging facility... I do not think we want to > introduce a lot of code for something like that. We enabled stackdepot on our system and realised, in long run stack depot consumes more runtime memory then it actually needs. we used shared patch to debug this issue. stack stores following two unique entries. Page allocation done in interrupt context will generate a unique stack trace. Consider following two entries. Entry 1: __alloc_pages_nodemask+0xec/0x200 page_frag_alloc+0x84/0x140 __napi_alloc_skb+0x83/0xe0 rtl8169_poll+0x1e5/0x670 net_rx_action+0x122/0x380 __do_softirq+0xce/0x298 irq_exit+0xa3/0xb0 ------------------- do_IRQ+0x72/0xc0 ret_from_intr+0x0/0x14 rw_copy_check_uvector+0x8a/0x100 import_iovec+0x27/0xc0 copy_msghdr_from_user+0xc0/0x120 ___sys_recvmsg+0x76/0x210 __sys_recvmsg+0x39/0x70 entry_SYSCALL_64_fastpath+0x13/ Entry 2: __alloc_pages_nodemask+0xec/0x200 page_frag_alloc+0x84/0x140 __napi_alloc_skb+0x83/0xe0 rtl8169_poll+0x1e5/0x670 net_rx_action+0x122/0x380 __do_softirq+0xce/0x298 irq_exit+0xa3/0xb0 ------------------- smp_apic_timer_interrupt+0x5b/0x110 apic_timer_interrupt+0x89/0x90 cpuidle_enter_state+0x95/0x2c0 do_idle+0x163/0x1a0 cpu_startup_entry+0x14/0x20 secondary_startup_64+0xa5/0xb0 Actual Allocation Path is __alloc_pages_nodemask+0xec/0x200 page_frag_alloc+0x84/0x140 __napi_alloc_skb+0x83/0xe0 rtl8169_poll+0x1e5/0x670 net_rx_action+0x122/0x380 __do_softirq+0xce/0x298 irq_exit+0xa3/0xb0 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. Regards, Vaneet Narang