Live data from Hacker News

60x speed-up of Linux “perf”

eighty-twenty.org

151–160 of 224 posts

Re: 60x speed-up of Linux “perf”

#151
post #2

Yet another case of GPL virality causing more issues than it solves. E: Downvoters, have you read the article? The program started a new process for each address lookup instead of using a library because that library is GPL. Shall we have a discussion?

The root cause is copyright. If it were to be abolished, no one would ever have to think about licensing ever again. None of this pain would exist. Think about all the time that would be saved when people no longer need to think about all this lawyer bullshit.

In the absence of copyright things like the GPL would have no power - a company could take your work and bundle it into their product and never contribute anything back ever.

Re: 60x speed-up of Linux “perf”

#152

Earlier quoted context omitted.

The code was always going to be possible to use under GPL2, even if it said GPL2+. It's not really placing their trust with anyone since they wouldn't lose anything. It's more of a flag waving op to keep corporate interest -- corporate are notoriously disinterested in GPL3 projects, so Linux devs basically said "ok let's not let anyone fork as GPL3 and make significant work we can't benefit from". Then Linux stays re…

This isn't true at all - Linus made the licensing decision in version 0.12 of the kernel, back in 1992! The certainly wasn't any corporate interest in Linux that needed to be protected back then. http://lkml.iu.edu/hypermail/linux/kernel/0009.1/0096.html

TIL, thanks. Guess cui bono isn't a reliable method of deduction.

Re: 60x speed-up of Linux “perf”

#153
Does anybody have working instructions to build a patched perf for Ubuntu 20.04? I built from kernel.org following https://michcioperz.com/post/slow-perf-script/, but somehow flamegraph pointed at the new build breaks totally -- after exiting the app, there's no "perf record: Woken up 181 times to write data" message; it just hangs.

Re: 60x speed-up of Linux “perf”

#154
post #122

Earlier quoted context omitted.

I think it's acceptable to not want an organisation to be able to relicense your software under arbitrary terms, which the GPL does allow the FSF to do. The GPL 3 is a pretty benign improvement on the GPL 2 (though I know Linus objects to the Tivo clause). I don't think anyone who was happy with their software being used under the terms of GPL 2 would be unhappy with it being used under the terms of the GPL 3 additio…

Would that >= license be enforceable in court? It seems lame to create a license that forces you to agree to whatever future license changes come about.

It could go several ways but I can't see a judge wanting to entertain complaints that a new GPL version isn't to your liking if the changes are minor, especially so since it's always going to remain valid in GPLv3.

If the FSF goes rogue and changes the GPL to be incredibly restrictive (i.e., allowing proprietary redistribution, and I realise this can be considered permissive..) it might be possible to get it to be ruled invalid defaulting to the more permissive licence, especially if you have deep pockets, or if the FSF change the licence to be ridiculously permissive like 0BSD then it's not going to be legal in countries like Germany, either way any major change is likely to result in an international enforcement nightmare.

Re: 60x speed-up of Linux “perf”

#155
post #86

Oh no I hoped it was about speeding up perf record that is actually a big thorn on my side, one I wrote a specific tool for... Depending on the number of probes you use, perf record can induce large latency hits or reduced throughput. Batching/buffer disk writes solves the problem for me. But I had to redevelop a perf parser to record/compress smarter. And for network streaming (no touching the disk is even better...…

Sorry! :-) It was very much just scratching a particular itch I had related to cargo-flamegraph...

Perf report is indeed slow AF, especially on large files, you're right in wanting to speed it up! Thanks for sharing! This is an interesting tidbit that has thrown me down a rabbit hole of 'profiling the profiler'...

Re: 60x speed-up of Linux “perf”

#156

Earlier quoted context omitted.

Most GPL licenses permits their code to be redistributed as the same GPL version or any later version of the GPL, Linux releases as GPLv2 or later for example. Perf does not permit the license to be redistributed as anything except GPLv2, so it conflicts with GPLv3 code.

“Linux releases as GPLv2 or later for example” Linux doesn’t use “or later”. https://github.com/torvalds/linux/blob/master/COPYING : The Linux Kernel is provided under: SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note Being under the terms of the GNU General Public License version 2 only, according with: LICENSES/preferred/GPL-2.0 With an explicit syscall exception, as stated at: LICENSES/exceptions/Linux-sys…

[deleted]

Re: 60x speed-up of Linux “perf”

#157
post #82

Earlier quoted context omitted.

The issue is that the only way to guarantee no liability is a clean room implementation. It's why most open source reimplementations require no mention or examination of the source/machine code. Google got dinged over a trivial method they copied in their java implementation, even though it was extremely trivial. You can't risk any chance of copying, regardless of how trivial the code.

Patent and copyright trolls have shown that even a clean room implementation is no guarantee .

True, but at least you as the employee won't get fired since you can't be blamed.

Re: 60x speed-up of Linux “perf”

#158

Oh no I hoped it was about speeding up perf record that is actually a big thorn on my side, one I wrote a specific tool for... Depending on the number of probes you use, perf record can induce large latency hits or reduced throughput. Batching/buffer disk writes solves the problem for me. But I had to redevelop a perf parser to record/compress smarter. And for network streaming (no touching the disk is even better...…

Neat! Is your tool open source? It'd be nice if perf record had a fundamentally faster way of working. I found a nice description of how it works in the README.md for cargo-trace: "perf relies on perf_event_open_sys to sample the stack. Every time a sample is taken, the entire stack is copied into user space. Stack unwinding is performed in user space as a post processing step. This wastes bandwidth and is a security…

I'll ask about opensourcing the tool. But just in case, the recipe is to use pipe mode and pre-parse all frames, stream them as messages, sometimes to several targets (pub/sub) with some streaming-zstd, and also splitting the pmu/probes/Intel-PT streams and treating them separately. Stack-traces are analysed (precomputed cfg optimised structure so unwinding is faster) before storing in adhoc in-house format with all other system traces. Only annoying thing is changing perf-record settings (pid changes, need event X, new probe) means restart and I ran out of interns before we had no-loss switchover...

Re: 60x speed-up of Linux “perf”

#159
post #3

> Michał Sidor suggests building against libbfd, something that the Debian maintainers don’t want to do. "don't want to" isn't quite correct - they can't . Perf is licensed under the GPLv2, libbfd under the GPLv3. The licenses are incompatible, which makes the combination unredistributable - which is what Debian would be doing with it. Debian is legally not allowed to do this.

Debian could provide a tool which builds it for you, on your system, right? The resulting binary would not be redistributable but you could use it. I've often wondered why more linux distros don't provide a similar tool to build ZFS into the kernel for you.

Debian nicely offers this with the zfs-dkms package.

Ubuntu just bundles ZFS into the kernel statically - not even as a loadable module - and damn the licensing implications(!).

Re: 60x speed-up of Linux “perf”

#160
post #42

Earlier quoted context omitted.

The most recent exploitation of opensource code comes from Amazon & friends making their own paid, hosted versions of redis, elastic search, mongodb, and so on. And not making any sort of proportionate contribution to the developers - whose free work their profits entirely rely on. And in this case I’m not sure how gpl helps. With gpl2 you only need to distribute source code if you distribute binaries - so they have…

That’s a shortcoming of the GPL: it doesn’t consider interactions over the network “distribution”. It’s the reason the AGPL exists. IMHO, GPL software that could be expected to run in SaaS form should be AGPL.

It's also worth noting that GPL become more accepted in the corporate world because SaaSS defanged it. AGPL is toxic to companies now, but when everyone was releasing desktop software, GPL was treated the same way.
Post reply on HN