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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37086C001E0 for ; Mon, 14 Aug 2023 17:23:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229605AbjHNRW3 (ORCPT ); Mon, 14 Aug 2023 13:22:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230173AbjHNRW1 (ORCPT ); Mon, 14 Aug 2023 13:22:27 -0400 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E61B1E7D for ; Mon, 14 Aug 2023 10:22:26 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id 3f1490d57ef6-d669fcad15cso4086605276.0 for ; Mon, 14 Aug 2023 10:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692033746; x=1692638546; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=K4kC8VdwRVtwS3SYD2fsCeGdVP47xqsJs+F+kjoCJt8=; b=QqppkQfZcvfWKp0It6PxdXG5wNPjeRybUln6bQP8usjcp6RMH5wdXv1pvsVdvDExGS Dr5dCDXITZC90isqbPTyutvnqunbZPro5WAvYsA9voVOv6TaBx1VSZGE802vliYDCYoX fcFBS1cIrABZu/1ip1lg34dU3gW4ZKm1j1hheQ1kQHLLoDtvairF5/EPr2G1by0E7KSu 1Asyfx2MwfavXPE8ucSm9UOGGv77HBqnkZipeuSRLAiBp/M4mMHZnxpo8d6myONS35Qq lPZZ3tyF0Vgik1AkmzSM2spr3KzohzpW4y5CJ5dt8t+xi1JuTeJ5mRYZSq5ATh2thErn by+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692033746; x=1692638546; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=K4kC8VdwRVtwS3SYD2fsCeGdVP47xqsJs+F+kjoCJt8=; b=ObadwU0JquwvbXBsMh9jH4n9WV5x2JYczfcrW6/QJl21RFaUV/mo74zvrjEWfXJ20S HIgpM3E9lLuxxoufS5hJoG/CI1SzSp6CWJ9mIpa3xMbOyb804w3FTOCRpBKKDdykvHKT Tlvy8H6LBctPOPoZhU0MnKfbsUw66tVPkgrRdWu1inxZw9g/CsXq2nYVC9oUDok9hILc NPbwySQaB2xStJ3M1AWABqbA5YnCuFDc9r7MBabDXxynM8Gl+1c9cIiFSwB5iqyoyvk3 T/uUnd/Uvl75MhODeKrWocKuGsNb+Pn4HI/ESVXPBbbAzjjSfvcKPkG9yyCxGr1xryPf WQ+Q== X-Gm-Message-State: AOJu0YzpxUD5EQuKMctzvsyOmjC4JzCY/TK/qcXhh2rVDpQZWx+beRrO Rs93xV6g3SP0j2Ky8+SKLrUY2js= X-Google-Smtp-Source: AGHT+IHZ6W/zTV2xaZIGU94xFjfsD19UE705tAS9fruZGyiFxbrRi8Qkewej2Rt6Eky1W/eR4dbeEbo= X-Received: from sdf.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5935]) (user=sdf job=sendgmr) by 2002:a05:6902:1084:b0:d09:17f2:d3b0 with SMTP id v4-20020a056902108400b00d0917f2d3b0mr150604ybu.9.1692033746236; Mon, 14 Aug 2023 10:22:26 -0700 (PDT) Date: Mon, 14 Aug 2023 10:22:24 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230812055703.7218-1-rtoax@foxmail.com> Message-ID: Subject: Re: [PATCH bpf-next v3] selftests/bpf: trace_helpers.c: optimize kallsyms cache From: Stanislav Fomichev To: Rong Tao Cc: ast@kernel.org, rongtao@cestc.cn, Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Hao Luo , Jiri Olsa , Mykola Lysenko , Shuah Khan , "open list:BPF [GENERAL] (Safe Dynamic Programs and Tools)" , "open list:KERNEL SELFTEST FRAMEWORK" , open list Content-Type: text/plain; charset="utf-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/12, Rong Tao wrote: > From: Rong Tao > > Static ksyms often have problems because the number of symbols exceeds the > MAX_SYMS limit. Like changing the MAX_SYMS from 300000 to 400000 in > commit e76a014334a6("selftests/bpf: Bump and validate MAX_SYMS") solves > the problem somewhat, but it's not the perfect way. > > This commit uses dynamic memory allocation, which completely solves the > problem caused by the limitation of the number of kallsyms. > > Signed-off-by: Rong Tao I believe this is the one that won the pw race: https://patchwork.kernel.org/project/netdevbpf/patch/tencent_50B4B2622FE7546A5FF9464310650C008509@qq.com/ Acked-by: Stanislav Fomichev > --- > v3: Do not use structs and judge ksyms__add_symbol function return value. > v2: https://lore.kernel.org/lkml/tencent_B655EE5E5D463110D70CD2846AB3262EED09@qq.com/ > Do the usual len/capacity scheme here to amortize the cost of realloc, and > don't free symbols. > v1: https://lore.kernel.org/lkml/tencent_AB461510B10CD484E0B2F62E3754165F2909@qq.com/ > --- > tools/testing/selftests/bpf/trace_helpers.c | 42 ++++++++++++++++----- > 1 file changed, 32 insertions(+), 10 deletions(-) > > diff --git a/tools/testing/selftests/bpf/trace_helpers.c b/tools/testing/selftests/bpf/trace_helpers.c > index f83d9f65c65b..d8391a2122b4 100644 > --- a/tools/testing/selftests/bpf/trace_helpers.c > +++ b/tools/testing/selftests/bpf/trace_helpers.c > @@ -18,10 +18,32 @@ > #define TRACEFS_PIPE "/sys/kernel/tracing/trace_pipe" > #define DEBUGFS_PIPE "/sys/kernel/debug/tracing/trace_pipe" > > -#define MAX_SYMS 400000 > -static struct ksym syms[MAX_SYMS]; > +static struct ksym *syms; > +static int sym_cap; > static int sym_cnt; > > +static int ksyms__add_symbol(const char *name, unsigned long addr) > +{ > + void *tmp; > + unsigned int new_cap; Nit: reverse Christmas tree, not sure we care for the tests though..