Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp191385imj; Fri, 15 Feb 2019 21:24:51 -0800 (PST) X-Google-Smtp-Source: AHgI3IbD23ikzxBhFUUQ9a4r/cIA6k+viknNR9aB/uslJOmOFZHwVhqab0mqFLuJWdstHpnS/uJL X-Received: by 2002:a17:902:f091:: with SMTP id go17mr14175777plb.235.1550294691334; Fri, 15 Feb 2019 21:24:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550294691; cv=none; d=google.com; s=arc-20160816; b=PDfYVdLk4IdDM30G78YnzbWxwY6NL2azAHis9mGOj9sJ8lSVeEr7JooLoF+YEu/ZIi aHO6QLySkLBcx3buRWe0/7RFKNlZo+sFUBU/3aGXf3Kr5xCVYdkkVCytfQqDdvN9KBTd +vrxlnai4uQm57scV3YiM5syep9A20oXuRQZOdfFnubRtKKNrHNhKEcgF2lYEsQpDC68 5+32oggKWFw5gv7kxI8tinpoQdBx5KEZa/dG5BQwxU9hPQqjbTqmrr9TkxUqb4HcFek5 ksrxfGBlAXJ43YrqSzBEetnuREgjhchhM2DTiUFQQHeSH0dTrLZwQy6jByI3Cp4sGsUv Tjew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=zysHHuS9bMtbwBwzS5Vz7pjWwBRTPDr0AA3WMzy9px4=; b=gOCQ5t/12mR336C6dLyYUNPyrKLMvtM6ueLCBeRAxAzv3DOqYwDztIkcmtbUYP3Oyb nHgPNnYOQJisP2iSB00cFv9uhFSg6XDD3x1kcKCxVIUcNdIESS84zK0PZZ8k3wNMAAcn U1jbq6Gn8y/u5KQ4MyXATBgURBecAeg6qA0DnAgqBI2BFF1kZF/P/9C5Jngvf7fIh6SJ q+U/BCVTlTjpxuf1EyilCvTJiFmxQPMcBepOQWrrGP6wrBLzxKeSelaJCw+qmCpNTEHf PsO8wYQqXahHkOI+KVEkR5mlnWPZJ/KAwjlqnC9B4GJTRIr3SXUb05/02oUEajSc3fd1 ALBg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=JhSDRrbx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g4si7592311pfm.85.2019.02.15.21.24.35; Fri, 15 Feb 2019 21:24:51 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=JhSDRrbx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389290AbfBOSUw (ORCPT + 99 others); Fri, 15 Feb 2019 13:20:52 -0500 Received: from mail.kernel.org ([198.145.29.99]:57222 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388282AbfBOSUw (ORCPT ); Fri, 15 Feb 2019 13:20:52 -0500 Received: from quaco.ghostprotocols.net (unknown [190.15.121.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 960F52192C; Fri, 15 Feb 2019 18:20:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1550254850; bh=JKzKHbJHo02DoCYjbXvPTJtPRrs9NPF3mxMa8hEUyY0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JhSDRrbxtSPNA+XOz9Jf+Nsy82AS7QdzrLzm2xpKMXG0FtBU7cm6jl3PnP25QBrWJ yn4sF2WGjzAdLRaVQk529WiklnjUcQayirztvcZJWpsqx8wRu/B/MsbU1BslSH9o9j 1dWvqqC3P9JsC01bSacTHCSdOlRn0fQVfYLPZOvM= Received: by quaco.ghostprotocols.net (Postfix, from userid 1000) id 4A04F410D5; Fri, 15 Feb 2019 15:20:47 -0300 (-03) Date: Fri, 15 Feb 2019 15:20:47 -0300 From: Arnaldo Carvalho de Melo To: Song Liu Cc: Jiri Olsa , Stephane Eranian , Netdev , linux-kernel , Alexei Starovoitov , "daniel@iogearbox.net" , Kernel Team , "peterz@infradead.org" , "namhyung@kernel.org" Subject: Re: [PATCH v2 perf,bpf 08/11] perf, bpf: save btf information as headers to perf.data Message-ID: <20190215182047.GL31177@kernel.org> References: <20190214235624.2579307-1-songliubraving@fb.com> <20190215000010.2590505-1-songliubraving@fb.com> <20190215000010.2590505-7-songliubraving@fb.com> <20190215142643.GC5784@redhat.com> <164D19ED-EA72-4A56-8259-FCF13894B183@fb.com> <20190215174022.GF31177@kernel.org> <847940EC-6E2A-4985-AE19-27758C301B5D@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <847940EC-6E2A-4985-AE19-27758C301B5D@fb.com> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Fri, Feb 15, 2019 at 05:47:58PM +0000, Song Liu escreveu: > > > > On Feb 15, 2019, at 9:40 AM, Arnaldo Carvalho de Melo wrote: > > > > Em Fri, Feb 15, 2019 at 05:25:01PM +0000, Song Liu escreveu: > >>> On Feb 15, 2019, at 6:26 AM, Arnaldo Carvalho de Melo wrote: > >>> Em Thu, Feb 14, 2019 at 04:00:09PM -0800, Song Liu escreveu: > >>>> This patch enables perf-record to save btf information as headers to > >>>> perf.data A new header type HEADER_BTF is introduced for this data. > > > >>> Wouldn't it be better for this HEADER_BTF to be introduced > >>> already as an user space event, Song, see: > > > >>> tools/perf/util/event.h > > > >>> and: > > > >>> tools/perf/util/event.c > > > >>> perf_event__synthesize_cpu_map() > > > >> BTF would be short living for short living BPF programs. I guess > >> saving them as header is easier than merging them with samples. > > > >> What's the benefit of saving them as user space events? > > > > When we work with pipe mode, i.e.: > > > > perf record -o - | perf report -i - > > > > and other combinations (with 'perf script', 'perf inject', etc), we need > > a way to pass the headers to the other side, and the way was via user > > space events. > > > > This is something Stephane and Jiri have been discussing recently, > > probably they have more justifications, Stephane, Jiri? > > > > - Arnaldo > > I see. In this case, we will need some synchronization between main > thread and the polling thread, as they are both writing to the same > pipe. So, the whole context is that we need to have 'perf record' to start a thread per CPU and then read the already per-cpu mmap buffers in the matching thread, with the right affinity, numa settings to have the record phase not cause contention, etc, so it ends up dumping one stream per CPU in a separate file in a 'perf.data' directory instead of a perf.data file. Jiri is working on that, so, if you dump one more stream into that directory, it would, at post processing time, be ordered together with the other stream, the per-cpu ones. - Arnaldo