Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp2939803rwb; Wed, 30 Nov 2022 13:03:18 -0800 (PST) X-Google-Smtp-Source: AA0mqf7MiWNp+5YeHbf3zvAKFf9Ocy1lIPmlebaV59VlBRLOBOZ445Rf9MnNlNKirhuxF//G53bJ X-Received: by 2002:a17:906:2604:b0:78a:d0a4:176 with SMTP id h4-20020a170906260400b0078ad0a40176mr54828930ejc.720.1669842197832; Wed, 30 Nov 2022 13:03:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669842197; cv=none; d=google.com; s=arc-20160816; b=dHzmpyIzlJlYQo5npDgyOzEZdMCEk+oetFeJMVtBIizR2zfqZXPr8JSafsQWITMxJw 32SAOqlVoxNbb3jLQq8b9amSui1DabhZkoI8eXz+/hmJdSj35F/NjRdzOvrFNZhrDJfr WYeOSRetypmk0n5Vl+W7OQauEQbetgONj0tOU6ewxQxJyGTKaXpcXL4WfoR1cZCAaRWt t0ohJbKwwTlDj9UdO1r5bAH3doz1LURs4HER4ikrFR22vg3Pmvu55eJfWbIKcjdHOJ8g vtuOexT9G+3vc0xe3HBuQL2SZ1GYwWWALpkaJqI1tQh4j26uso9du3vDOuMd4/s8K6/1 MXiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=2AAz1p3amdjSsxmPSJU+uGZAdAbSjyxAbikHqGyzpmk=; b=b5319tYDGiH+9lGt3r3PpHZs1/eseYNIByleqb0mQgx5uZQDxb13rUTtCGba0zflKA SghBZlAQW46nivKqhAJofZZ+zFtjY8rth+elJhwrkgSLThLuPrhG74Pp0aS3DE7UFps+ 2DBunJtng2NePGk9JSRr25NNAPbnLveLXQtMwieHDg5vbz2Q0oVZlEOGqr65mSLuaF1u HcmGm5vFszY7BEyASTeTXO3f8AnMo9tab8YWyVzS5+IHABuVgfuuoe9yFjR+yiR3r5na b4fX2PA9mOPGGQrhrBuqVrloZYnhjnExoxkhLQmWXWTQ1chMFEGq1ucxuYQwOQGyvASk WJTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=nCNaAYb3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sd8-20020a1709076e0800b007ae43ee86aesi2285114ejc.69.2022.11.30.13.02.56; Wed, 30 Nov 2022 13:03:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=nCNaAYb3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230160AbiK3USD (ORCPT + 83 others); Wed, 30 Nov 2022 15:18:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230344AbiK3URU (ORCPT ); Wed, 30 Nov 2022 15:17:20 -0500 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BF67189328 for ; Wed, 30 Nov 2022 12:13:24 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id w15so15736322wrl.9 for ; Wed, 30 Nov 2022 12:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2AAz1p3amdjSsxmPSJU+uGZAdAbSjyxAbikHqGyzpmk=; b=nCNaAYb3XzkERXQkz2iPfkCS79RviSzmXslWPza+frd/CWKfVpYgJwneIY7uYo0TJE kTbxjGHIjrWKsDkbC77zJRHJIZY8KNuLnUwx/6LFHKUJ0Rj35SAew4DrxVajLXWcYNoW 5+VTUZzEfuSwVKPFQK4L3hTKlZtN51Lpl0yL7hQ80XRYqz0ZZUMpdy+61UlN2IBdNAD+ kje/YBR6vT4oA5Pw74sFZBmbBKnW8QtQtP4ngiGm3HefZOjiJ0OTB/tKpK6i943h0XvF SqljAkss+WFcGjsgETKJIo3dhnHpqwyKWI2GcEMp0dJSvYtIIePuC5E68lx1PbHNWYpQ qfGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2AAz1p3amdjSsxmPSJU+uGZAdAbSjyxAbikHqGyzpmk=; b=KqZlDccJr5QWAFb6VFjKvFgOdmexi5sjI5gUgLHWf3Dw00shpViu5c+0HDqBr2wyAC DPh2fpDMRSvq9unTK0DifG7WpKk2pTvsVZyOxfma0Ev2UO4HkpJ6gjZmM0DHbpLJGyot 1HdkfxrG/EMnRbDmPvqSGTPwEkSc9LYnYKZaAP1Cg+lEdpQAj5GGHAjx5YGeDZPyVP2t BEUB8olmphHoYqXd9QkUnZrrAxXsquL9k3OkkveY/rOGPi5ztrQwtpJwfQWcY9EQdnIQ stegHRNbPVieZQ2X97rf8Xshfydiz6UKZLjmFj1gI0FZFYjbytWqTov3ocOy0jcf+w3k wFaw== X-Gm-Message-State: ANoB5pmhu5KfdQe2yRUTSwMV7uB8+fCUdqllwMAIZfzC0+JeIOGBlvTW A7IU1/lvTIkop4hJrmd/igeodpeJNBDkgXb8wIreQQ== X-Received: by 2002:adf:e64f:0:b0:241:e2f1:8b44 with SMTP id b15-20020adfe64f000000b00241e2f18b44mr25818541wrn.300.1669839202034; Wed, 30 Nov 2022 12:13:22 -0800 (PST) MIME-Version: 1.0 References: <20221130062935.2219247-1-irogers@google.com> <20221130062935.2219247-4-irogers@google.com> In-Reply-To: From: Ian Rogers Date: Wed, 30 Nov 2022 12:13:10 -0800 Message-ID: Subject: Re: [PATCH v2 3/4] perf build: Use libtraceevent from the system To: Namhyung Kim Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Masami Hiramatsu , Steven Rostedt , Adrian Hunter , Leo Yan , Kan Liang , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Stephane Eranian Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 30, 2022 at 11:05 AM Namhyung Kim wrote: > > On Tue, Nov 29, 2022 at 10:30 PM Ian Rogers wrote: > > > > Remove the LIBTRACEEVENT_DYNAMIC and LIBTRACEFS_DYNAMIC. If > > libtraceevent isn't installed or NO_LIBTRACEEVENT=1 is passed to the > > build, don't compile in libtraceevent and libtracefs support. This > > also disables CONFIG_TRACE that controls "perf > > trace". CONFIG_TRACEEVENT is used to control enablement in > > Build/Makefiles, HAVE_LIBTRACEEVENT is used in C code. Without > > HAVE_LIBTRACEEVENT tracepoints are disabled and as such the commands > > kmem, kwork, lock, sched and timechart are removed. The majority of > > commands continue to work including "perf test". > > Maybe we can have a different approach. I guess the trace data > access is isolated then we can make dummy interfaces when there's > no libtraceevent. This way we don't need to touch every command > and let it fail when it's asked. Sounds like a worthwhile refactor that can land on top of this change. > The motivation is that we should be able to run the sub-commands > as much as possible. In fact, we could run 'record' part only on the > target machine and pass the data to the host for analysis with a > full-fledged perf. Also some commands like 'perf lock contention' > can run with or without libtraceevent (using BPF only). The issue here is that perf lock contention will use evsel__new_tp and internally that uses libtraceevent. As such it is removed without HAVE_LIBTRACEEVENT. Without the evsel there's not much perf lock contention can do, so rather than litter the code with HAVE_LIBTRACEEVENT and for it to be broken, I made the choice just to remove it from the no libtraceevent build for now. I think it is worth pursuing these patches in the shape they are in so that we can land the removal of tools/lib/traceevent and ensure the migration away from an out-of-date version of that library. Thanks, Ian > Thanks, > Namhyung