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;
From:   Song Liu <songliubraving@fb.com>
To:     Arnaldo Carvalho de Melo <acme@kernel.org>
CC:     Jiri Olsa <jolsa@kernel.org>,
        Stephane Eranian <eranian@google.com>,
        Netdev <netdev@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Alexei Starovoitov <ast@kernel.org>,
        "daniel@iogearbox.net" <daniel@iogearbox.net>,
        Kernel Team <Kernel-team@fb.com>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "namhyung@kernel.org" <namhyung@kernel.org>
Subject: Re: [PATCH v2 perf,bpf 08/11] perf, bpf: save btf information as
 headers to perf.data
Thread-Topic: [PATCH v2 perf,bpf 08/11] perf, bpf: save btf information as
 headers to perf.data
Thread-Index: AQHUxMGQlShe9E029kWf9/H0QeuOj6Xg626AgAAx0ACAAARLAIAAAh+AgAAJLICAAAq9gA==
Date:   Fri, 15 Feb 2019 18:59:14 +0000
Message-ID: <F6877640-F6A6-4F2D-B756-0092D7B1237F@fb.com>
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>
 <20190215182047.GL31177@kernel.org>
In-Reply-To: <20190215182047.GL31177@kernel.org>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: fb.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F543B53B4445A243AC564E79EDE092A8@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4572d16f-f5ac-40ce-2941-08d69377adc3
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2019 18:59:14.4032
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1629
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-02-15_13:,,
 signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On Feb 15, 2019, at 10:20 AM, Arnaldo Carvalho de Melo <acme@kernel.org> =
wrote:
>=20
> Em Fri, Feb 15, 2019 at 05:47:58PM +0000, Song Liu escreveu:
>>=20
>>=20
>>> On Feb 15, 2019, at 9:40 AM, Arnaldo Carvalho de Melo <acme@kernel.org>=
 wrote:
>>>=20
>>> 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 <acme@redhat.co=
m> 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.
>>>=20
>>>>> 	Wouldn't it be better for this HEADER_BTF to be introduced
>>>>> already as an user space event, Song, see:
>>>=20
>>>>> tools/perf/util/event.h
>>>=20
>>>>> and:
>>>=20
>>>>> tools/perf/util/event.c
>>>=20
>>>>> perf_event__synthesize_cpu_map()
>>>=20
>>>> BTF would be short living for short living BPF programs. I guess=20
>>>> saving them as header is easier than merging them with samples.=20
>>>=20
>>>> What's the benefit of saving them as user space events?
>>>=20
>>> When we work with pipe mode, i.e.:
>>>=20
>>> 	perf record -o - | perf report -i -
>>>=20
>>> and other combinations (with 'perf script', 'perf inject', etc), we nee=
d
>>> a way to pass the headers to the other side, and the way was via user
>>> space events.
>>>=20
>>> This is something Stephane and Jiri have been discussing recently,
>>> probably they have more justifications, Stephane, Jiri?
>>>=20
>>> - Arnaldo
>>=20
>> 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.=20
>=20
> 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.
>=20
> 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.
>=20
> - Arnaldo

I see. This solution looks great.=20

For this set, how about I keep this part as-is (at least for v3)? In=20
this case, it will goes to the header file after Jiri's change. Once=20
Jiri's work is done, I will move them into per-cpu files.=20

Thanks,
Song