From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33A7FC433DB for ; Fri, 26 Feb 2021 14:16:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5F4BF64F03 for ; Fri, 26 Feb 2021 14:16:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5F4BF64F03 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8FC726B0006; Fri, 26 Feb 2021 09:16:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8AC896B006C; Fri, 26 Feb 2021 09:16:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E9366B006E; Fri, 26 Feb 2021 09:16:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0197.hostedemail.com [216.40.44.197]) by kanga.kvack.org (Postfix) with ESMTP id 657226B0006 for ; Fri, 26 Feb 2021 09:16:00 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 2F88B40E1 for ; Fri, 26 Feb 2021 14:16:00 +0000 (UTC) X-FDA: 77860618080.06.5A9097C Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf20.hostedemail.com (Postfix) with ESMTP id 0BDF23503 for ; Fri, 26 Feb 2021 14:15:53 +0000 (UTC) Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BB7B464ED5; Fri, 26 Feb 2021 14:15:51 +0000 (UTC) Date: Fri, 26 Feb 2021 09:15:50 -0500 From: Steven Rostedt To: Jacob Wen Cc: Linus Torvalds , Andrew Morton , Joe Perches , Christoph Lameter , Joonsoo Kim , Linux-MM , mm-commits@vger.kernel.org, Paul McKenney , Pekka Enberg , David Rientjes Subject: Re: [patch 014/173] mm, tracing: record slab name for kmem_cache_free() Message-ID: <20210226091550.36473054@gandalf.local.home> In-Reply-To: <301b57a6-8630-d3a0-699a-361c2df9f561@oracle.com> References: <20210224115824.1e289a6895087f10c41dd8d6@linux-foundation.org> <20210224200055.U7Xz47kX5%akpm@linux-foundation.org> <20210224203708.4489755a@oasis.local.home> <20210224210740.73273c7a@oasis.local.home> <5a0b6fb4-6efd-e391-45fa-cd188f181d5d@oracle.com> <20210225093128.4cd86439@gandalf.local.home> <20210225125741.4fc7e43e@gandalf.local.home> <81645797-baee-fb17-6432-6a5cc423f09b@oracle.com> <20210225215640.51feee2f@oasis.local.home> <301b57a6-8630-d3a0-699a-361c2df9f561@oracle.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: 1oe4agjpjf7kxwnb3h4j3rzmjp9xybhi X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 0BDF23503 Received-SPF: none (kernel.org>: No applicable sender policy available) receiver=imf20; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: none/none X-HE-Tag: 1614348953-226494 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 26 Feb 2021 11:48:18 +0800 Jacob Wen wrote: > Removing a kernel module to see if it releases a lot of memory is > helpful to quickly find out the root causes of some issues. > > It seems nice to reserve the symbols. I don't have a relevant use case > so it's just my 2 cents. It's much more complex than that. We do something similar, where we keep the kallsyms for the module init code (otherwise when tracing a module that is loaded, you wont be able to see its functions). But the complexity comes from the fact that kallsyms has addresses associated to functions that no longer exist. Now what happens when new code maps at those addresses? It confuses kallsyms. Yeah, unloading of a module will turn function names into their original address, and worse, can even show function names for new code added. But there's not much we can do without having to save all kallsyms that were ever loaded, along with time stamps to know when they were valid. And remember, this is all in kernel memory that is never swapped out. If you want to add a feature to do something like that go ahead. I would recommend a "time out" where after a given time (user defined) that older symbols are flushed from the system, and perhaps even allow the user to define the number of symbols to keep around after they are gone. At least this will let the users decide how much memory they want to waste for this. -- Steve