Received-SPF: pass (google.com: domain of linux-kernel+bounces-194510-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240529065311.1218230-1-namhyung@kernel.org> <Zlbn3DOGrzHlw95h@krava>
 <CAM9d7ci0g+ObA7w-tXU9cyjzRUFgXjZ4b9Atx2+oV4Anhraeyg@mail.gmail.com>
In-Reply-To: <CAM9d7ci0g+ObA7w-tXU9cyjzRUFgXjZ4b9Atx2+oV4Anhraeyg@mail.gmail.com>
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Wed, 29 May 2024 10:23:10 -0700
Message-ID: <CAADnVQ+qqx8=WjpMjZyqzCb+02zpw9=wVAwWfyHL_O4Xpadukw@mail.gmail.com>
Subject: Re: [PATCH v2] bpf: Allocate bpf_event_entry with node info
To: Namhyung Kim <namhyung@kernel.org>
Cc: Jiri Olsa <olsajiri@gmail.com>, Alexei Starovoitov <ast@kernel.org>, 
	Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>, 
	Martin KaFai Lau <martin.lau@linux.dev>, Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>, 
	Yonghong Song <yonghong.song@linux.dev>, John Fastabend <john.fastabend@gmail.com>, 
	KP Singh <kpsingh@kernel.org>, Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>, 
	LKML <linux-kernel@vger.kernel.org>, bpf <bpf@vger.kernel.org>, 
	Aleksei Shchekotikhin <alekseis@google.com>, Nilay Vaish <nilayvaish@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 29, 2024 at 9:54=E2=80=AFAM Namhyung Kim <namhyung@kernel.org> =
wrote:
>
> Hi Jiri,
>
> On Wed, May 29, 2024 at 1:31=E2=80=AFAM Jiri Olsa <olsajiri@gmail.com> wr=
ote:
> >
> > On Tue, May 28, 2024 at 11:53:11PM -0700, Namhyung Kim wrote:
> > > It was reported that accessing perf_event map entry caused pretty hig=
h
> > > LLC misses in get_map_perf_counter().  As reading perf_event is allow=
ed
> > > for the local CPU only, I think we can use the target CPU of the even=
t
> > > as hint for the allocation like in perf_event_alloc() so that the eve=
nt
> > > and the entry can be in the same node at least.
> >
> > looks good, is there any profile to prove the gain?
>
> No, at this point.  I'm not sure if it'd help LLC hit ratio but
> I think it should improve the memory latency.

I have the same concern as Jiri.
Without numbers this is just a code churn.
Does this patch really make a difference?
Without numbers maintainers would have to believe the "just trust me" part.
So..
pw-bot: cr