Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3993480pxb; Tue, 25 Jan 2022 00:55:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJzLdLveUfnVixLYpUjmskQlPKto3CzRMfWNK9ywcc/DOgZBJh627xRGRG05rHucZ77sy4fw X-Received: by 2002:a17:907:7d86:: with SMTP id oz6mr8318393ejc.532.1643100937803; Tue, 25 Jan 2022 00:55:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643100937; cv=none; d=google.com; s=arc-20160816; b=BlaQDgWvE+6jHOJ/NgWx3AiKQzFgrWNa3hml07xRGjRveam9FhhJsBSyik3AfvW+o5 i8OUpa8GAxO3T2gahI/+mjVNm8E+O7NB9FpsNTatIE5ZTdLoAVgTJJzMh2y+p+BlgC1i C8fJLEEWcSJ/B7M4MTzAIPNlMYf7UcGqmnNaJ/kb6HcfzIGerikY6OEcevnp4E6P60vk 3+11EbnAJRSE0CX0T16eOGNImX10I2us8cWXuSI/WZWsaSxVJVjxdR58/t8nGM5jVYHp U3vrMCWeTJDEDauD2DArWF4wb1c8FikoWlyNpwbz2bQlxiDeNA447X30RNx9cX/wPe0y k7JQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from; bh=gnSNQDi/W8U5c9mBFabdyXEgTrlOeu+FJvD/ULWgJVE=; b=ZECj4T2QWzVDjmLDFJW9RpepYLlvNVR7oYSOIVAUS47DSdYZ9RoQ21g992iW/YO9OO MDFsPRK+DkcEb2AmqiUccw8tcA4N6ffBv6gC7I7I9jvPlFSh+tzOrW5gPJDeWIw6KaR5 ZTwUClC2iNhaCJ8Sk0Kw2YmD6KP/qNI88VZBH9jx8GCuXihcjm1QeNulnPAa0uHN19og UB3T6i1dBGHwUrRooVkfHzQqZXv0biBVTNWXeFVTWaDUWr9nlKWy5z0+qPMI9j9qM6g0 utA1LEkzjReN4n0bBnDb0TQZDU1fVRoOOYtsQwMsIWb5XDvX3xAEZW1swm70aXu3aUnK NGXw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id qf26si1374741ejc.912.2022.01.25.00.55.13; Tue, 25 Jan 2022 00:55:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241250AbiAYEs2 (ORCPT + 99 others); Mon, 24 Jan 2022 23:48:28 -0500 Received: from szxga01-in.huawei.com ([45.249.212.187]:35862 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S248059AbiAYD4Q (ORCPT ); Mon, 24 Jan 2022 22:56:16 -0500 Received: from canpemm500010.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4JjY0V70sgzcck5; Tue, 25 Jan 2022 11:55:22 +0800 (CST) Received: from huawei.com (10.67.189.167) by canpemm500010.china.huawei.com (7.192.105.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 25 Jan 2022 11:56:11 +0800 From: Jiangfeng Xiao To: , , , , , , , , , , , , CC: , Subject: [PATCH] [PING] perf dso: Avoid copying redundant kallsyms in th buildid_dir Date: Tue, 25 Jan 2022 11:56:01 +0800 Message-ID: <1643082961-8535-1-git-send-email-xiaojiangfeng@huawei.com> X-Mailer: git-send-email 1.8.5.6 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.67.189.167] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To canpemm500010.china.huawei.com (7.192.105.118) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The issue is occurs in following step: (1)copy the kernel module (such as test.ko) to /root directory (2)load the kernel module (such as insmod test.ko) (3)run perf-record as: perf record sleep 1 Then /proc/kallsyms will be copied not only to /root/.debug/[kernel.kallsyms]//kallsyms, but also be copied to /root/.debug/[test]//kallsyms(this is redundant). Say a kallsyms file content takes 5MB memory, 100 out-of-tree kernel modules will take 500MB, which is not bearable on embedded environment. __cmd_record(): __perf_session__new(): perf_session__create_kernel_maps(): machine__create_kernel_maps(): machine__create_modules(): machine__set_modules_path(): perf will only search for kernel modules in "/lib/modules/`uname -r`/" /root/test.ko is not in scope. maps__set_modules_path_dir(): maps__set_module_path(): dso__set_long_name(): the dso->long_name of test.ko has not changed, it is still [test]. record__finish_output(): perf_session__write_header(): [...] dso__cache_build_id(): bool is_kallsyms = dso__is_kallsyms(dso); dso__is_kallsyms(): return dso->kernel&&dso->long_name[0] != '/'; [test] will be wrongly judged as kallsyms, and then the value of is_kallsyms is true. build_id_cache__add_b(, is_kallsyms,): build_id_cache__add_s(, is_kallsyms,): build_id_cache__add(, is_kallsyms,): if (is_kallsyms) copyfile("/proc/kallsyms", filename): /proc/kallsyms will be copied to /root/.debug/[test]//kallsyms. Why can this modification can avoid the redundancy of kallsyms: if (dso->kernel == DSO_SPACE__KERNEL) there are only two possibilities, one is dso__is_kallsyms, and the other is dso__is_kmod. After modification, [test] is no longer incorrectly judged as kallsyms. Why can dso__is_kmod judge correctly? __cmd_record(): __perf_session__new(): perf_session__create_kernel_maps(): machine__create_kernel_maps(): machine__create_modules(): modules__parse(): for each line in /proc/modules, not just in "/lib/modules/`uname -r`/". machine__create_module(): machine__addnew_module_map(): machine__findnew_module_dso(): dso__set_module_info(): assign dso->symtab_type to DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE and so on. Reported-by: Lexi Shao Signed-off-by: Jiangfeng Xiao --- tools/perf/util/dso.h | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h index 011da39..57a6ab5 100644 --- a/tools/perf/util/dso.h +++ b/tools/perf/util/dso.h @@ -380,9 +380,17 @@ static inline bool dso__is_kcore(struct dso *dso) dso->binary_type == DSO_BINARY_TYPE__GUEST_KCORE; } +static inline bool dso__is_kmod(struct dso *dso) +{ + return dso->symtab_type == DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE || + dso->symtab_type == DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE_COMP || + dso->symtab_type == DSO_BINARY_TYPE__GUEST_KMODULE || + dso->symtab_type == DSO_BINARY_TYPE__GUEST_KMODULE_COMP; +} + static inline bool dso__is_kallsyms(struct dso *dso) { - return dso->kernel && dso->long_name[0] != '/'; + return dso->kernel && !dso__is_kmod(dso); } void dso__free_a2l(struct dso *dso); -- 1.8.5.6