a few libperf questions

a few libperf questions

[Vince Weaver]

Hello

I work on various perf-related tools in the HPC community, most notably 
the PAPI performance library.

Currently PAPI maintains its own independent code for working with 
perf_event_open(), but with the advent of libperf I was looking into maybe 
linking against libperf to avoid all the code/work duplication.  So I had 
a few questions.

	1. What's the licensing of libperf?  Is it GPLv2?

		PAPI is BSD licensed.
		This is something that actually pushes us to libperf
		because if I wanted to (for example) implement the new 
		ARM rdpmc code I can't just copy it in to PAPI but
		would have to re-implement from scratch

	2. Is it expected that distributions will start shipping
		libperf?  As part of perf or otherwise?

		Telling HPC users they need to dowload an entire
		kernel tree just to build libperf is seen as a huge
		obstacle for many, and just including a snapshot
		of the code into our code tree again starts having
		licensing issues.

	3. Is libperf planned to be backwards compatible with old kernels,
		or will it be tied to whatever kernel it is shipped with?
		Will it have ABI-stable releases?

		Sort of like with perf, I know only supporting the most
		recent kernel makes life easier for the kernel developers
		but it does make for a library versioning nightmare
		especially if trying to support people on older
		distro releases.

I'm going to try to see if I can get a libperf backend for PAPI going and 
maybe try to get some of the other HPC parties involved (they tend to not 
want to deal with kernel development directly for some reason) but I'm not 
sure if they're going to like how closely bound libperf is to 
the kernel tree.

Vince Weaver
vincent.weaver@maine.edu

Re: a few libperf questions

[Ian Rogers]

On Thu, Jun 2, 2022 at 8:38 AM Vince Weaver <vincent.weaver@maine.edu> wrote:
>
> Hello
>
> I work on various perf-related tools in the HPC community, most notably
> the PAPI performance library.
>
> Currently PAPI maintains its own independent code for working with
> perf_event_open(), but with the advent of libperf I was looking into maybe
> linking against libperf to avoid all the code/work duplication.  So I had
> a few questions.
>
>         1. What's the licensing of libperf?  Is it GPLv2?
>
>                 PAPI is BSD licensed.
>                 This is something that actually pushes us to libperf
>                 because if I wanted to (for example) implement the new
>                 ARM rdpmc code I can't just copy it in to PAPI but
>                 would have to re-implement from scratch

I believe that as code in libperf was copied from perf it retains the
GPL-2.0-only license. Some new code is "LGPL-2.1 OR BSD-2-Clause",
which makes more sense and would align libperf with libbpf. We've
talked about rewriting this code in Rust, perhaps when that is done
the more permissive license could be used.

>         2. Is it expected that distributions will start shipping
>                 libperf?  As part of perf or otherwise?
>
>                 Telling HPC users they need to dowload an entire
>                 kernel tree just to build libperf is seen as a huge
>                 obstacle for many, and just including a snapshot
>                 of the code into our code tree again starts having
>                 licensing issues.

There is a Makefile and an install step, however, I would say libperf
is *not* ready to be distributed. There was a lot of cleanup effort to
make libbpf 1.0 and similar should happen to libperf. I particularly
loathe perf_cpu_map__empty, which isn't doing what it says on the tin.

>         3. Is libperf planned to be backwards compatible with old kernels,
>                 or will it be tied to whatever kernel it is shipped with?
>                 Will it have ABI-stable releases?
>
>                 Sort of like with perf, I know only supporting the most
>                 recent kernel makes life easier for the kernel developers
>                 but it does make for a library versioning nightmare
>                 especially if trying to support people on older
>                 distro releases.

There is a myth that comes from Debian that perf only supports the
running kernel. This is wrong and means that bug fixes, improvements,
etc. are missed out on. This thread discusses it:
https://lore.kernel.org/linux-perf-users/CAP-5=fW7La9ZNv8Z6LHRRNXne4+dWK6dR1ye2P=zETFELtK=fg@mail.gmail.com/
It would be hugely impactful if someone could fix this, as a lot of
other distributions follow Debian.

Given perf doesn't have this problem and it is using libperf, I don't
think libperf has the problem.

> I'm going to try to see if I can get a libperf backend for PAPI going and
> maybe try to get some of the other HPC parties involved (they tend to not
> want to deal with kernel development directly for some reason) but I'm not
> sure if they're going to like how closely bound libperf is to
> the kernel tree.

Sounds good. The code is in the kernel tree but I'm not sure it is
"bound" to it.

Thanks,
Ian

> Vince Weaver
> vincent.weaver@maine.edu

Re: a few libperf questions

[Vince Weaver]

On Thu, 2 Jun 2022, Ian Rogers wrote:

> >         1. What's the licensing of libperf?  Is it GPLv2?
> >
> >                 PAPI is BSD licensed.
> >                 This is something that actually pushes us to libperf
> >                 because if I wanted to (for example) implement the new
> >                 ARM rdpmc code I can't just copy it in to PAPI but
> >                 would have to re-implement from scratch
> 
> I believe that as code in libperf was copied from perf it retains the
> GPL-2.0-only license. Some new code is "LGPL-2.1 OR BSD-2-Clause",
> which makes more sense and would align libperf with libbpf. We've
> talked about rewriting this code in Rust, perhaps when that is done
> the more permissive license could be used.

I was looking into this more, the various files have different licenses

linux.git/tools/lib/perf$ cat *.c Makefile | grep SPDX | uniq
// SPDX-License-Identifier: GPL-2.0-only
// SPDX-License-Identifier: GPL-2.0
# SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)

and this disagrees with what the documentation says:

linux.git/tools/lib/perf/Documentation/libperf-counting.txt 

LICENSE
-------
libperf is Free Software licensed under the GNU LGPL 2.1


I don't know which of these needs to be fixed to be more consistent.

Vince Weaver
vincent.weaver@maine.edu

Re: a few libperf questions

[Jiri Olsa]

On Thu, Jun 02, 2022 at 09:25:46AM -0700, Ian Rogers wrote:
> On Thu, Jun 2, 2022 at 8:38 AM Vince Weaver <vincent.weaver@maine.edu> wrote:
> >
> > Hello
> >
> > I work on various perf-related tools in the HPC community, most notably
> > the PAPI performance library.
> >
> > Currently PAPI maintains its own independent code for working with
> > perf_event_open(), but with the advent of libperf I was looking into maybe
> > linking against libperf to avoid all the code/work duplication.  So I had
> > a few questions.
> >
> >         1. What's the licensing of libperf?  Is it GPLv2?
> >
> >                 PAPI is BSD licensed.
> >                 This is something that actually pushes us to libperf
> >                 because if I wanted to (for example) implement the new
> >                 ARM rdpmc code I can't just copy it in to PAPI but
> >                 would have to re-implement from scratch
> 
> I believe that as code in libperf was copied from perf it retains the
> GPL-2.0-only license. Some new code is "LGPL-2.1 OR BSD-2-Clause",
> which makes more sense and would align libperf with libbpf. We've
> talked about rewriting this code in Rust, perhaps when that is done
> the more permissive license could be used.

yep, all the libperf code was copied from perf, so should have the
same license

> 
> >         2. Is it expected that distributions will start shipping
> >                 libperf?  As part of perf or otherwise?
> >
> >                 Telling HPC users they need to dowload an entire
> >                 kernel tree just to build libperf is seen as a huge
> >                 obstacle for many, and just including a snapshot
> >                 of the code into our code tree again starts having
> >                 licensing issues.
> 
> There is a Makefile and an install step, however, I would say libperf
> is *not* ready to be distributed. There was a lot of cleanup effort to
> make libbpf 1.0 and similar should happen to libperf. I particularly

it's currently packaged as sub package of kernel-tools in fedora:

	[jolsa@krava ~]$ rpm -qi libperf
	Name        : libperf
	Version     : 5.17.11
	Release     : 200.fc35
	Architecture: x86_64
	Install Date: Mon 30 May 2022 09:30:12 AM CEST
	Group       : Unspecified
	Size        : 109230
	License     : GPLv2
	Signature   : RSA/SHA256, Wed 25 May 2022 10:46:33 PM CEST, Key ID db4639719867c58f
	Source RPM  : kernel-tools-5.17.11-200.fc35.src.rpm
	Build Date  : Wed 25 May 2022 10:15:25 PM CEST
	Build Host  : bkernel01.iad2.fedoraproject.org
	Packager    : Fedora Project
	Vendor      : Fedora Project
	URL         : http://www.kernel.org/
	Bug URL     : https://bugz.fedoraproject.org/kernel-tools
	Summary     : The perf library from kernel source
	Description :
	This package contains the kernel source perf library.

not sure about other distros

> loathe perf_cpu_map__empty, which isn't doing what it says on the tin.

nice, that one should be easy to fix ;-)

jirka

> 
> >         3. Is libperf planned to be backwards compatible with old kernels,
> >                 or will it be tied to whatever kernel it is shipped with?
> >                 Will it have ABI-stable releases?
> >
> >                 Sort of like with perf, I know only supporting the most
> >                 recent kernel makes life easier for the kernel developers
> >                 but it does make for a library versioning nightmare
> >                 especially if trying to support people on older
> >                 distro releases.
> 
> There is a myth that comes from Debian that perf only supports the
> running kernel. This is wrong and means that bug fixes, improvements,
> etc. are missed out on. This thread discusses it:
> https://lore.kernel.org/linux-perf-users/CAP-5=fW7La9ZNv8Z6LHRRNXne4+dWK6dR1ye2P=zETFELtK=fg@mail.gmail.com/
> It would be hugely impactful if someone could fix this, as a lot of
> other distributions follow Debian.
> 
> Given perf doesn't have this problem and it is using libperf, I don't
> think libperf has the problem.

yes, same rules as for perf.. it should be backward compatible

jirka

> 
> > I'm going to try to see if I can get a libperf backend for PAPI going and
> > maybe try to get some of the other HPC parties involved (they tend to not
> > want to deal with kernel development directly for some reason) but I'm not
> > sure if they're going to like how closely bound libperf is to
> > the kernel tree.
> 
> Sounds good. The code is in the kernel tree but I'm not sure it is
> "bound" to it.
> 
> Thanks,
> Ian
> 
> > Vince Weaver
> > vincent.weaver@maine.edu