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=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 776ADC48BC2 for ; Mon, 28 Jun 2021 03:39:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5A8DB61363 for ; Mon, 28 Jun 2021 03:39:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232082AbhF1Dlq (ORCPT ); Sun, 27 Jun 2021 23:41:46 -0400 Received: from mail-lj1-f169.google.com ([209.85.208.169]:44861 "EHLO mail-lj1-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231678AbhF1Dlp (ORCPT ); Sun, 27 Jun 2021 23:41:45 -0400 Received: by mail-lj1-f169.google.com with SMTP id u25so7760472ljj.11 for ; Sun, 27 Jun 2021 20:39:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TA9GkBikXPkJmyUCmRN+fLpWXV97fC3gAkW1HN3aY3A=; b=SJOnmEDzsOmte1Cwt5WWx6xVcQt7vODZxGo2CjiXS2aWTvgxjNc6YM64KqRwjI7U/k 8nRERv6wPamq12OwLBtexFMJL6LwB6UHxLt4Gv803TvIBftClLZrHe/RubkbKGfWSi88 eulX/vV9rprvdwLkP2P+2IPXj3WYCCldD16+jLbjJBTNJ9GBuQmjY9PjI7rq3i5YaxRY 0k+PV1N3XnxJcH5tgXnj0Atb1enLMCtgTChJOYf4iBueaiJgQUpw6JLzVr5O89k5PtYs +LlUzUZvogif8bg/CgFjT+28qa21ducUSCW17Wly7OJAM/4+RhXVqsVn0lMCXZ3mmgkz u50w== X-Gm-Message-State: AOAM532Z5khF8a9aY10hdH5ZXtgJYd2szWEaqLftb6FgfE0sKR4dUMwQ HmR2YX4/wT4fozIGmAz4KG2HaSnnNABPjlRTLAU= X-Google-Smtp-Source: ABdhPJylA0BUC2OsncY/Qwk7/NHW3cORubGPCJoOy76H21YfiKPDZr8alwWFDLfz25eHHpJ+5DYfffNjqh3l9MzOWA0= X-Received: by 2002:a2e:8e82:: with SMTP id z2mr18085641ljk.275.1624851558515; Sun, 27 Jun 2021 20:39:18 -0700 (PDT) MIME-Version: 1.0 References: <20210622153918.688500-1-jolsa@kernel.org> In-Reply-To: From: Namhyung Kim Date: Sun, 27 Jun 2021 20:39:07 -0700 Message-ID: Subject: Re: [RFC 00/10] perf: Add build id parsing fault detection/fix To: Jiri Olsa Cc: Arnaldo Carvalho de Melo , Ian Rogers , lkml , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , Michael Petlan , Riccardo Mancini Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jun 27, 2021 at 10:25 AM Jiri Olsa wrote: > > On Wed, Jun 23, 2021 at 12:48:30PM -0700, Namhyung Kim wrote: > > Hi Jiri, > > > > Thanks for your work! > > > > On Tue, Jun 22, 2021 at 2:19 PM Jiri Olsa wrote: > > > > > > On Tue, Jun 22, 2021 at 03:14:04PM -0300, Arnaldo Carvalho de Melo wrote: > > > > Em Tue, Jun 22, 2021 at 10:47:54AM -0700, Ian Rogers escreveu: > > > > > On Tue, Jun 22, 2021 at 10:39 AM Arnaldo Carvalho de Melo > > > > > wrote: > > > > > > > > > > > > Em Tue, Jun 22, 2021 at 05:39:08PM +0200, Jiri Olsa escreveu: > > > > > > > hi, > > > > > > > this *RFC* patchset adds support to detect faults during > > > > > > > mmap2's build id parsing and a way to fix such maps in > > > > > > > generated perf.data. > > > > > > > > > > > > > > It adds support to record build id faults count for session > > > > > > > and store it in perf.data and perf inject support to find > > > > > > > these maps and reads build ids for them in user space. > > > > > > > > > > > > > It's probably best explained by the workflow: > > > > > > > > > > > > > > Record data with --buildid-mmap option: > > > > > > > > > > > > > > # perf record --buildid-mmap ... > > > > > > > ... > > > > > > > [ perf record: Woken up 1 times to write data ] > > > > > > > [ perf record: Failed to parse 4 build ids] > > > > > > > [ perf record: Captured and wrote 0.008 MB perf.data ] > > > > > > > > > > > > > > Check if there's any build id fault reported: > > > > > > > > > > > > > > # perf report --header-only > > > > > > > ... > > > > > > > # build id mmap stats: FAULTS 4, LOST 0, NOT FIXED > > > > > > > > > > > > > > There is, check the stats: > > > > > > > > > > > > > > # perf report --stat > > > > > > > > > > > > > > Aggregated stats: > > > > > > > TOTAL events: 104 > > > > > > > .... > > > > > > > BUILD_ID fails: 4 (14.3%) > > > > > > > > > > > > > > Yep, let's fix it: > > > > > > > > > > > > > > # perf inject --buildid-mmap2 -i perf.data -o perf-fixed.data > > > > > > > > > > > > Can we make it possible to automate this with --fixup-buildids or a > > > > > > perfconfig 'record' knob? > > > > > > > > > > > > This would entail requesting that build-ids that _fail_ be sent to the > > > > > > side-band thread we have in 'perf record', this way we wouldn't have to > > > > > > traverse the whole perf.data file, be it with 'perf-record' at the end > > > > > > of a session with faulty build ids, or in a similar fashion using 'perf > > > > > > inject' as you suggest. > > > > > > > > > > > > I even think that we can have all these modes and let the user to decide > > > > > > how important is this for them and how convenient they want the whole > > > > > > process to be. > > > > > > right, that might be good to decide first.. because as I said, > > > I never hit faulted build id, so it probably needs the special > > > setup you guys are using.. could you try on your setup and check > > > how many faulted build ids you see? > > > > Did you check data mmaps? It might be easy to get faults > > from data files and we don't know if it's an ELF or not > > before reading the ELF header in the first page. > > well, AFAICS the mmap event is sent right after the elf file > is loaded, so it does not have a chance to be swapped out I'm talking about the normal data files when we use perf record -d. Those mmap files might not have page 0 in memory. I'm afraid it's reported as a build-id fault. Thanks, Namhyung