Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp2085959pxb; Sat, 14 Nov 2020 12:46:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJy/BChV3dXYSA0KcZ0fy07LoV8xEDQMB16d5nSCTn5UsjPASoH/3MmPQyZH7VJPIwXPpoEn X-Received: by 2002:a17:906:3a4e:: with SMTP id a14mr7928952ejf.140.1605386796007; Sat, 14 Nov 2020 12:46:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605386795; cv=none; d=google.com; s=arc-20160816; b=Ro/KMPK3HfgM6QE6N6F/AagagjTmqrEY7cBKiG35Sij8hRmbfcKN0IF+xfiZbx49go WNOJL2V+c9OFzDUo526jKwLwoPB6MMOkM+drUAMl3maFvKO9Gi/nnR9/O3OFpGW0dMK0 BkdiiwbZOS7e5J4DfsCBq31dLLJL+lxATJzz3KC8I/WZUJHUzIDQzFCb1KUMrzUaImcj 5VY6vswhlH93xSky61S+mGEfOn3R2OPl4ynuZTAgzNCWiinD8yKSkQVK2Mv8T0RvF/FN gVUd7LoheZ6OcQC2EkcB4e8eBnTmWmCfeT/H54L9IJQbtuMRp3H/zglbG5hIzF2tqVg6 dZzw== 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=p1WDI73qmGI0DsbBcCGMG7Ea4nfKcBZVtW/kE1GC25s=; b=pI3HcO8FB5SzW3m2yxhGVXETicxqPXm6RYezVI3pauZHl3UZjwsjRDdDSAG4KoN8v9 Eh9h+HUkr4RfOPcSvLZMluWRn/GpxsFa28SjQSnIO+md0IUrne+4+J2g3m+PE5U3RzHz I5wc+Vwawrn0Bl6SZX1auToqbuPeGGSN/CbL+pnsQej8INO5gcq22QWVWKJoTswUophp fHURA3EiWduKFw9AwQ/J7q/QHoiLGExO84e0gWa+QchbULBPeAakAbbH3YQCW0Jt8oFU rNvHUiWfSfRGk/bo93OHaYvOJgisBPZT8FcyG2aSd6UCmGInxHBisgLlAjds0DpnXRz5 NWSg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hp9ZxSXW; 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 l31si8693376edl.524.2020.11.14.12.46.13; Sat, 14 Nov 2020 12:46:35 -0800 (PST) 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=hp9ZxSXW; 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 S1726227AbgKNUof (ORCPT + 99 others); Sat, 14 Nov 2020 15:44:35 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:53644 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726189AbgKNUoe (ORCPT ); Sat, 14 Nov 2020 15:44:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605386673; 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=p1WDI73qmGI0DsbBcCGMG7Ea4nfKcBZVtW/kE1GC25s=; b=hp9ZxSXWUvk80ij1gO5r3atG4bEcECnt1Iyjax9HubGpd8gWCT+T+Cx7uw7A5qztEgBtWU lJ6pOzT6rtzMPPZbcDQP8VdLzf5gGv0zTBX71KJ92yoOhZwBuXCKhPZ7wVUgWQzbxqs5hO 3JdpJm5ZGpQDskhFk01ZV+ZAYwHOv6Q= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-528-8S4OxrQUPySDJFptN3f07Q-1; Sat, 14 Nov 2020 15:44:30 -0500 X-MC-Unique: 8S4OxrQUPySDJFptN3f07Q-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AF9CF809DC3; Sat, 14 Nov 2020 20:44:28 +0000 (UTC) Received: from krava (unknown [10.40.192.25]) by smtp.corp.redhat.com (Postfix) with SMTP id 216955576C; Sat, 14 Nov 2020 20:44:24 +0000 (UTC) Date: Sat, 14 Nov 2020 21:44:24 +0100 From: Jiri Olsa To: Namhyung Kim Cc: Jiri Olsa , Arnaldo Carvalho de Melo , lkml , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , Michael Petlan , Song Liu , Ian Rogers , Stephane Eranian , Alexey Budankov , Andi Kleen , Adrian Hunter Subject: Re: [PATCH 24/24] perf record: Add --buildid-mmap option to enable mmap's build id Message-ID: <20201114204424.GA903902@krava> References: <20201109215415.400153-1-jolsa@kernel.org> <20201109215415.400153-25-jolsa@kernel.org> <20201113044000.GC167797@google.com> <20201113110926.GE753418@krava> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 14, 2020 at 09:31:56AM +0900, Namhyung Kim wrote: > On Fri, Nov 13, 2020 at 8:09 PM Jiri Olsa wrote: > > > > On Fri, Nov 13, 2020 at 01:40:00PM +0900, Namhyung Kim wrote: > > > On Mon, Nov 09, 2020 at 10:54:15PM +0100, Jiri Olsa wrote: > > > > Adding --buildid-mmap option to enable build id in mmap2 events. > > > > It will only work if there's kernel support for that and it disables > > > > build id cache (implies --no-buildid). > > > > > > > > It's also possible to enable it permanently via config option > > > > in ~.perfconfig file: > > > > > > > > [record] > > > > build-id=mmap > > > > > > You also need to update the documentation. > > > > right, forgot doc for the config option > > > > SNIP > > > > > > "append timestamp to output filename"), > > > > OPT_BOOLEAN(0, "timestamp-boundary", &record.timestamp_boundary, > > > > @@ -2657,6 +2662,21 @@ int cmd_record(int argc, const char **argv) > > > > > > > > } > > > > > > > > + if (rec->buildid_mmap) { > > > > + if (!perf_can_record_build_id()) { > > > > + pr_err("Failed: no support to record build id in mmap events, update your kernel.\n"); > > > > + err = -EINVAL; > > > > + goto out_opts; > > > > + } > > > > + pr_debug("Enabling build id in mmap2 events.\n"); > > > > + /* Enable mmap build id synthesizing. */ > > > > + symbol_conf.buildid_mmap2 = true; > > > > + /* Enable perf_event_attr::build_id bit. */ > > > > + rec->opts.build_id = true; > > > > + /* Disable build id cache. */ > > > > + rec->no_buildid = true; > > > > > > I'm afraid this can make it miss some build-id in the end because of > > > the possibility of the failure. > > > > with following fix (already merged): > > b33164f2bd1c bpf: Iterate through all PT_NOTE sections when looking for build id > > > > I could see high rate of build id being retrieved > > > > I'll make new numbers for next version, but I think we can neglect > > the failure, considering that we pick only 'hit' objects out of all > > of them > > > > also enabling the build id cache for this would go against the > > purpose why I'd like to have this.. so hopefuly the numbers > > will be convincing ;-) > > Yeah, I think it'd be ok for most cases but we cannot guarantee.. > What about checking the dso list at the end of a record session > and check all of them having build-id? Then we can safely skip > the build-id collecting stage. Hmm.. but it won't work for the pipe. how about inject command that would add missing buildids to mmap2 events jirka