linux-kernel - Re: [patch] Performance Counters for Linux, v3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7c86c4470812130944s5d2898ffpa28878ee4f51936a@mail.gmail.com>
Date:	Sat, 13 Dec 2008 18:44:50 +0100
From:	"stephane eranian" <eranian@...glemail.com>
To:	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>
Cc:	"Vince Weaver" <vince@...ter.net>, "Ingo Molnar" <mingo@...e.hu>,
	linux-kernel@...r.kernel.org,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Eric Dumazet" <dada1@...mosbay.com>,
	"Robert Richter" <robert.richter@....com>,
	"Arjan van de Veen" <arjan@...radead.org>,
	"Peter Anvin" <hpa@...or.com>, "Paul Mackerras" <paulus@...ba.org>,
	"David S. Miller" <davem@...emloft.net>,
	Papi <ptools-perfapi@...utk.edu>
Subject: Re: [patch] Performance Counters for Linux, v3

Peter,

I don't think you understand what libpfm actually does and therefore
you rush to the wrong conclusion.

At its core, libpfm does NOT know anything about the perfmon kernel API.

I think you missed that, unfortunately.

It is a helper library which helps tool writer solves the event-> code
-> counter assignment problems.
That's it. It does not make any perfmon syscall at ALL to do that.
Proof is people have been using it on
Windows, I can also use it on MacOS.

Looking at your proposal, you think you won't need such a library and
that the kernel is
going to do all this for you. Let's go back to your kerneltop program:

KernelTop Options (up to 4 event types can be specified):

 -e EID    --event_id=EID     # event type ID                     [default:  0]
                                  0: CPU cycles
                                  1: instructions
                                  2: cache accesses
                                  3: cache misses
                                  4: branch instructions
                                  5: branch prediction misses
                                < 0: raw CPU events

Looks like I can do:

$ kerneltop --event_id=-0x510088

You think users are going to come up with 0x510088 out of the blue?

I want to say:

$ kerneltop --event_id=BR_INST_EXEC --plm=user

Where do you think they are going to get that from?

The kernel or a helper user library?

Do not denigrate other people's software without understanding what it does.


On Sat, Dec 13, 2008 at 12:17 PM, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> On Fri, 2008-12-12 at 18:42 +0100, stephane eranian wrote:
>> In fact, I know tools which do not even need a library.
>
> By your own saying, the problem solved by libperfmon is a hard problem
> (and I fully understand that).
>
> Now you say there is software out there that doesn't use libperfmon,
> that means they'll have to duplicate that functionality.
>
> And only commercial software has a clear gain by wastefully duplicating
> that effort. This means there is an active commercial interest to not
> make perfmon the best technical solution there is, which is contrary to
> the very thing Linux is about.
>
> What is worse, you defend that:
>
>> Go ask end-users what they think of that?
>>
>> You don't even need a library. All of this could be integrated into the tool.
>> New processor, just go download the updated version of the tool.
>
> No! what people want is their problem fixed - no matter how. That is one
> of the powers of FOSS, you can fix your problems in any way suitable.
>
> Would it not be much better if those folks duped into using a binary
> only product only had to upgrade their FOSS kernel, instead of possibly
> forking over more $$$ for an upgrade?
>
> You have just irrevocably proven to me this needs to go into the kernel,
> as the design of perfmon is little more than a GPL circumvention device
> - independent of whether you are aware of that or not.
>
> For that I hereby fully NAK perfmon
>
> Nacked-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/