Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5063833pxj; Tue, 22 Jun 2021 14:22:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzBpdoNYWvX3rYE4czqYiHf/DEIe5awMcAmjmhljx9CyknBxT/r4EPtK+Ro27tPS5k7kUHU X-Received: by 2002:a05:6402:12da:: with SMTP id k26mr198298edx.10.1624396968975; Tue, 22 Jun 2021 14:22:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624396968; cv=none; d=google.com; s=arc-20160816; b=SvKDdo/4h3VEaSCF6+nbjPbjRe6Ok6oGDeEP1ijBCxca1WDb0pWDJAVNhJHV5MQFx/ U9yXthz/zWzUaLjLFy+hKiKT9kK7TJb8SR8ajLyQER3RMsnnejNYih2lRDGZwAsTqtha BH09WW2E4lplY6hB/FfythEb6pBX6IrnozR0fm3HtDDu0QsDY5IIwJEA+f9ZPhq2Q5R7 Z+Smx2LPMWf4WYEB3yPQLJZjpPy0B5TFsdbkKawWiOi9mRQ0x7Qj9tTU/Z7RhakeqL8L mc+/O0Vh1b+ZhpvXL1F62OQzjWd/vcnAUOKpabF1/ThYScgsqLmhu4On3akG/wYP6D8Q odHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=XlNdNVJJaT0poBG4McRO9fS++ltdFMf7gkDA4rZ1bU4=; b=sUWRsRYSGsbZcfHjYpWEihZOOqwwFa9PuUFD6JlkszL51SktAb6N1ahrTwKOx9ZjHV aCLD7YHJRZ34VD+YHYzBpbh9y0j1m9V3K/qTtGI8aLPY8zVXw0J9Jz39Gzd6cQuILa7a ulQHpkjGghhecQgkzeb+WcCuBwC58ybLG1G+iJ5KCpp8+yFrXj2KbWyb9+avWcZyGRsZ i6qiWCtG4b5dy97WMEimRjzL6y5WlJZ/fTmYpiTyorkZSLHSFyjF08FjCbsivGTMtx6Z eudbXoaVAk9CUg8VZMUCcVkOfvp9KGVfXZgc5loy1PfNlz1svz5pNq3AWB+vRZ7Zk3PA Kq/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Q8mxc4Wj; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cz9si19043192edb.398.2021.06.22.14.22.25; Tue, 22 Jun 2021 14:22:48 -0700 (PDT) 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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Q8mxc4Wj; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229918AbhFVVVk (ORCPT + 99 others); Tue, 22 Jun 2021 17:21:40 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:56253 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229625AbhFVVVj (ORCPT ); Tue, 22 Jun 2021 17:21:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1624396762; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XlNdNVJJaT0poBG4McRO9fS++ltdFMf7gkDA4rZ1bU4=; b=Q8mxc4WjZmPJeQWfI7mU0LwU/cqP8cdOe0HoXA78VUELq3VbfBXFl3uVbJT182Q/1YKvkl 1EhMTYFkYVd4eKBW9UP0qkKldRy/eZ4Z3RN6R/2svNmvgbz9CjDk2vMvN6noy+3SrecwdQ TnnIf1StMAUdD8CdJopqcRfCW4qs0Kw= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-420-wMFrQ2iUMmOTDTsASuVWig-1; Tue, 22 Jun 2021 17:19:21 -0400 X-MC-Unique: wMFrQ2iUMmOTDTsASuVWig-1 Received: by mail-wr1-f71.google.com with SMTP id j2-20020a5d61820000b029011a6a8149b5so73894wru.14 for ; Tue, 22 Jun 2021 14:19:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=XlNdNVJJaT0poBG4McRO9fS++ltdFMf7gkDA4rZ1bU4=; b=GMsU5x8UscQHR24qeoyH8dTJeRgpmLFXbzx5nDKvEptZikeRd+MA0wO0ydFIXwOkIO jPj8JU7yFQY2IUVJTpKHTbWaX2pw9IeiRzNSqHRa5+/yjyuVqsK7BZ9fjXIKWaSDH9Zy pIXJzSArSrPNV6goaggA2tCath0M87sCK7Z3MlOojP0YE6T/oD5cxEOZ1VgMsWAzLTp4 LsgCXxSt5rMOTBJ0quKKvXyl7m2k+vW7c9qNFyhYbhTnqA8IaldlkOH8SEs1/Rkb6+zS E1v1eSJq3UrMglbYu5Cyl8EU2U8iH8QuTTBJvFHst453ACXm3ekh0NMcLRtHlEpcG0Fa AVdg== X-Gm-Message-State: AOAM5300B3b13tEGu7IL53hEQQxsHqyWOPR0vHHxXPz10s3zTxpZFZOn AILZkEiT84iVgcTWtPmhYaawfykVgRYltVAwkcae5wChyQPlDETOufeWwuMyoOXK2vl5wf9xA2a lsasZcpXmVTVefGfGI7aXZCGQ X-Received: by 2002:a05:600c:281:: with SMTP id 1mr6434999wmk.171.1624396760252; Tue, 22 Jun 2021 14:19:20 -0700 (PDT) X-Received: by 2002:a05:600c:281:: with SMTP id 1mr6434991wmk.171.1624396760055; Tue, 22 Jun 2021 14:19:20 -0700 (PDT) Received: from krava ([5.171.245.189]) by smtp.gmail.com with ESMTPSA id g17sm680337wrh.72.2021.06.22.14.19.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Jun 2021 14:19:19 -0700 (PDT) Date: Tue, 22 Jun 2021 23:19:15 +0200 From: Jiri Olsa To: Arnaldo Carvalho de Melo , Ian Rogers Cc: lkml , Peter Zijlstra , Ingo Molnar , Mark Rutland , Namhyung Kim , Alexander Shishkin , Michael Petlan , rickyman7@gmail.com Subject: Re: [RFC 00/10] perf: Add build id parsing fault detection/fix Message-ID: References: <20210622153918.688500-1-jolsa@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? thanks, jirka