Re: a few libperf questions

[Jiri Olsa <olsajiri@gmail.com>]

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