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:     Jiri Olsa <jolsa@redhat.com>
CC:     Adrian Hunter <adrian.hunter@intel.com>,
        Jiri Olsa <jolsa@kernel.org>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        lkml <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@kernel.org>,
        Namhyung Kim <namhyung@kernel.org>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>,
        Andi Kleen <ak@linux.intel.com>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>
Subject: Re: [PATCH 11/12] perf tools: Reuse shared eBPF dso objects
Thread-Topic: [PATCH 11/12] perf tools: Reuse shared eBPF dso objects
Thread-Index: AQHU9G3HZKG3RseEUUSmcxz4FyjxX6Y/5qcAgAAEcoCAAAEcgIAACmmAgACdlAA=
Date:   Wed, 17 Apr 2019 16:56:41 +0000
Message-ID: <4CBDB645-513F-4CCA-9FA0-B29110F10C0E@fb.com>
References: <20190416160127.30203-1-jolsa@kernel.org>
 <20190416160127.30203-12-jolsa@kernel.org>
 <746f02e3-a509-5081-8427-b610e52c1fb0@intel.com>
 <20190417065127.GA17024@krava>
 <ed2f881b-c1b2-e6da-5c23-fc1eb4db131f@intel.com>
 <20190417073241.GC17024@krava>
In-Reply-To: <20190417073241.GC17024@krava>
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: <FDEEDA285DFEFA438EF49FFE3DEE59FF@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 70817bc3-0491-44eb-8c07-08d6c355aa43
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 16:56:41.4182
 (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: MWHPR15MB1504
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-17_07:,,
 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 Apr 17, 2019, at 12:32 AM, Jiri Olsa <jolsa@redhat.com> wrote:
>=20
> On Wed, Apr 17, 2019 at 09:55:25AM +0300, Adrian Hunter wrote:
>> On 17/04/19 9:51 AM, Jiri Olsa wrote:
>>> On Wed, Apr 17, 2019 at 09:35:32AM +0300, Adrian Hunter wrote:
>>>> On 16/04/19 7:01 PM, Jiri Olsa wrote:
>>>>> The eBPF program can be loaded multiple times
>>>>> with the same name (tag). We can share dso
>>>>> objects for those programs.
>>>>=20
>>>> Doesn't a eBPF program get recompiled differently every time it is loa=
ded?
>>>=20
>>> yes, but those with same tag are identical
>>=20
>> But won't recompiled eBPF programs be different due to blinded constants=
?
>> Or perhaps in the future other code randomization?
>=20
> ah right.. that can happen, let's skip this one then
>=20
> perhaps we could add bpf prog id to be part of the name
> to make it unique.. I'll check
>=20
> thanks,
> jirka

I thought about similar optimizations. However, this is not easy.=20

Tag of a BPF program is calculated _before_ JiT, so we really cannot
say two programs with same tag are identical. Current implementation=20
iterates over all bpf program IDs, so same program id will not appear
twice in the same perf session.=20

I think the more realistic opportunity of optimizations comes from=20
sharing the dsos cross multiple perf.data files.=20

Thanks,
Song

>>=20
>>>=20
>>> jirka
>>>=20
>>>>=20
>>>>>=20
>>>>> Link: http://lkml.kernel.org/n/tip-3damf8vq1dryhtpbk5b06jpt@git.kerne=
l.org
>>>>> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
>>>>> ---
>>>>> tools/perf/util/machine.c | 14 +++++++++++---
>>>>> 1 file changed, 11 insertions(+), 3 deletions(-)
>>>>>=20
>>>>> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
>>>>> index d4aa44489011..a60653827891 100644
>>>>> --- a/tools/perf/util/machine.c
>>>>> +++ b/tools/perf/util/machine.c
>>>>> @@ -23,6 +23,7 @@
>>>>> #include "linux/hash.h"
>>>>> #include "asm/bug.h"
>>>>> #include "bpf-event.h"
>>>>> +#include "dso.h"
>>>>>=20
>>>>> #include "sane_ctype.h"
>>>>> #include <symbol/kallsyms.h>
>>>>> @@ -699,11 +700,18 @@ static int machine__process_ksymbol_register(st=
ruct machine *machine,
>>>>>=20
>>>>> 	map =3D map_groups__find(&machine->kmaps, event->ksymbol_event.addr)=
;
>>>>> 	if (!map) {
>>>>> -		map =3D dso__new_map(event->ksymbol_event.name);
>>>>> -		if (!map)
>>>>> +		struct dso *dso;
>>>>> +
>>>>> +		dso =3D dsos__findnew(&machine->dsos, event->ksymbol_event.name);
>>>>> +		if (!dso)
>>>>> 			return -ENOMEM;
>>>>>=20
>>>>> -		map->start =3D event->ksymbol_event.addr;
>>>>> +		map =3D map__new2(event->ksymbol_event.addr, dso);
>>>>> +		if (!map) {
>>>>> +			dso__put(dso);
>>>>> +			return -ENOMEM;
>>>>> +		}
>>>>> +
>>>>> 		map->end =3D map->start + event->ksymbol_event.len;
>>>>> 		map_groups__insert(&machine->kmaps, map);
>>>>> 	}