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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable 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 33840C43381 for ; Thu, 7 Mar 2019 14:05:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 089C52081B for ; Thu, 7 Mar 2019 14:05:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726361AbfCGOFv (ORCPT ); Thu, 7 Mar 2019 09:05:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41468 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726127AbfCGOFu (ORCPT ); Thu, 7 Mar 2019 09:05:50 -0500 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 mx1.redhat.com (Postfix) with ESMTPS id 9AA57883CA; Thu, 7 Mar 2019 14:05:49 +0000 (UTC) Received: from krava (unknown [10.40.206.1]) by smtp.corp.redhat.com (Postfix) with SMTP id 609E25D783; Thu, 7 Mar 2019 14:05:47 +0000 (UTC) Date: Thu, 7 Mar 2019 15:05:46 +0100 From: Jiri Olsa To: Song Liu Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, kernel-team@fb.com, peterz@infradead.org, acme@redhat.com, jolsa@kernel.org, namhyung@kernel.org Subject: Re: [PATCH v6 perf,bpf 06/15] perf, bpf: save bpf_prog_info in a rbtree in perf_env Message-ID: <20190307140546.GC7233@krava> References: <20190306071359.2359896-1-songliubraving@fb.com> <20190306071359.2359896-7-songliubraving@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190306071359.2359896-7-songliubraving@fb.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 07 Mar 2019 14:05:49 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 05, 2019 at 11:13:50PM -0800, Song Liu wrote: > bpf_prog_info contains information necessary to annotate bpf programs. > This patch saves bpf_prog_info for bpf programs loaded in the system. > > Some big picture of the next few patches: > > To fully annotate BPF programs with source code mapping, 4 different > information are needed: > 1) PERF_RECORD_KSYMBOL > 2) PERF_RECORD_BPF_EVENT > 3) bpf_prog_info > 4) btf > > Before this set, 1) and 2) in the list are already saved to perf.data > file. For BPF programs that are already loaded before perf run, 1) and 2) > are synthesized by perf_event__synthesize_bpf_events(). For short living > BPF programs, 1) and 2) are generated by kernel. > > This set handles 3) and 4) from the list. Again, it is necessary to handle > existing BPF program and short living program separately. > > This patch handles 3) for exising BPF programs while synthesizing 1) and > 2) in perf_event__synthesize_bpf_events(). These data are stored in > perf_env. The next patch saves these data from perf_env to perf.data as > headers. > > Similarly, the two patches after the next saves 4) of existing BPF > programs to perf_env and perf.data. > > Another patch later will handle 3) and 4) for short living BPF programs > by monitoring 1) and 2) in a dedicate thread. > thanks for the changelog SNIP > + > + /* save bpf_prog_info to env */ > + info_node = malloc(sizeof(struct bpf_prog_info_node)); > + > + /* > + * Do not bail out for !info_node, as we still want to > + * call perf_tool__process_synth_event() > + */ well, we are out of memory, so I dont think perf_tool__process_synth_event will get too far.. also the perf_env data would be inconsistent with what you store as event.. how can that work? jirka > + if (info_node) { > + info_node->info_linear = info_linear; > + perf_env__insert_bpf_prog_info(env, info_node); > + info_linear = NULL; > + } SNIP