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 B5203C6FD19 for ; Thu, 16 Mar 2023 17:50:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230326AbjCPRuy (ORCPT ); Thu, 16 Mar 2023 13:50:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55338 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230256AbjCPRut (ORCPT ); Thu, 16 Mar 2023 13:50:49 -0400 Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F23B145B62 for ; Thu, 16 Mar 2023 10:50:33 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id bp11so1434587ilb.3 for ; Thu, 16 Mar 2023 10:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1678989031; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=wVREMZ5kpSW/gc2Ge3hXpJkQknE5nkfYCVcEvxv4EXI=; b=asLa2HDFhrf4l/5L/rbsFjIMDSD0pGnamZAh61JnlEKslGh4/ioiqBPX5uimZuV0/A l9Uu2x/ecW9+abZ5qSQlxUkjLcxSO4AjWkr2OAV6V20nTK80dRjDAVHq9s4SNcHZaCTh b/EMGCnN6cbq8pBPRyI3yiSwd4l+szi8F2T9/R/zJdHOpp2H+nZM+3rja9gmrjzL09aV 8lzePT6Z0KcwYBoJ83jCr/EoE3t87+M/o+qfIQ5LGn+BHwcypDU2tBHD+I1ut+qd2cmS ccWeNJOdkJgAGQDu7tIrozPi3pqswZfkqeC1NtX9dIp0M+C033XYN3Mw5Raq2rTKVtl0 qSug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678989031; h=content-transfer-encoding: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=wVREMZ5kpSW/gc2Ge3hXpJkQknE5nkfYCVcEvxv4EXI=; b=hInHBD7o7RaeW2RAghmyAsINW7fRpMfbEquq9LpjuJGzmJnFGNGUG39DIBC5MwnjSv 7FF1/DzKSCYuPt3/S17YFrp8cl6oFK1xGmJSYVRz3/fOqosxiSP4t/XBBJMwZnFkp5aJ j9vqBKBLPC7E8nqC7k4/jC9KjuScm08EQfsBgX5T+umohCZApFr2H8iuDUcPf399dzj6 8GnyYtXivJcSPaduvOXf3fNa9/wBW+bs5RnJewyungYqQ088f+ZjI6Biu/XUfhFFGhnt Zhltxh3MvF9tebOSLIrnYXZJQ4fITqniRxsMnGzCdibCeWLOtUjuXCTX4EM1zgeIZsMN 7Yag== X-Gm-Message-State: AO0yUKVEs48URBlIloKLeH0xEE8rDKW3LHLai1dEeMG+jn1Jn84/Ci48 EX8y9T14/gIzDxp+f0IUt9OGnmnH2A7FdVmnjsbO6Q== X-Google-Smtp-Source: AK7set8mXf20D2vvZ13VDFjuQCTRthMKZlP5n2x8/krArMampywj3ASCIlATMoK0zgwEG6o2Ok5YuhGPd3VwvvLLZVk= X-Received: by 2002:a92:c542:0:b0:313:93c8:e71b with SMTP id a2-20020a92c542000000b0031393c8e71bmr243410ilj.15.1678989031152; Thu, 16 Mar 2023 10:50:31 -0700 (PDT) MIME-Version: 1.0 References: <20230316170149.4106586-1-jolsa@kernel.org> In-Reply-To: From: Ian Rogers Date: Thu, 16 Mar 2023 10:50:16 -0700 Message-ID: Subject: Re: [PATCHv3 bpf-next 0/9] mm/bpf/perf: Store build id in file object To: Matthew Wilcox Cc: Jiri Olsa , Alexei Starovoitov , Andrii Nakryiko , Hao Luo , Andrew Morton , Alexander Viro , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , bpf@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-perf-users@vger.kernel.org, Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Daniel Borkmann , Namhyung Kim , Dave Chinner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, Mar 16, 2023 at 10:35=E2=80=AFAM Matthew Wilcox wrote: > > On Thu, Mar 16, 2023 at 06:01:40PM +0100, Jiri Olsa wrote: > > hi, > > this patchset adds build id object pointer to struct file object. > > > > We have several use cases for build id to be used in BPF programs > > [2][3]. > > Yes, you have use cases, but you never answered the question I asked: > > Is this going to be enabled by every distro kernel, or is it for special > use-cases where only people doing a very specialised thing who are > willing to build their own kernels will use it? > > Saying "hubble/tetragon" doesn't answer that question. Maybe it does > to you, but I have no idea what that software is. > > Put it another way: how does this make *MY* life better? Literally me. > How will it affect my life? So at Google we use build IDs for all profiling, I believe Meta is the same but obviously I can't speak for them. For BPF program stack traces, using build ID + offset stack traces is preferable to perf's whole system synthesis of mmap events based on data held in /proc/pid/maps. Individual stack traces are larger, but you avoid the ever growing problem of coming up with some initial virtual memory state that will allow you to identify samples. This doesn't answer the question about how this will help you, but I expect over time you will see scalability issues and also want to use tools assuming build IDs are present and cheap to access. Thanks, Ian