The AppArmor Performance Impact In 70+ Benchmarks On Linux 5.5 Git

[phoronix]

Phoronix: The AppArmor Performance Impact In 70+ Benchmarks On Linux 5.5 Git

With bisecting one of the big regressions in Linux 5.5 and finding the culprit to be an AppArmor change while using Hackbench as one of the most affected tests, I was curious to see what other workloads are impacted big by AppArmor on the current Linux 5.5 Git code. Here are 72 tests with the Threadripper 3970X on Linux 5.5 Git when toggling AppArmor...

http://www.phoronix.com/scan.php?page=news_item&px=AppArmor-Linux-5.5-72-Tests

[timofonic]

Were you able to detect the responsible commit of that performance regression? What about a more fine grained test against all commits up to 5.5-git? Please make it happen.

What about asking for resources and financing to the Linux Foundation to make PTS even more suitable for Linux kernel development?

[Britoid]

Curious to see SELinux benchmarks.

Given SELinux is much more in-depth and further reaching than AppArmor, I honestly expect it to be worst, but then it has more development so maybe not?

[boxie]

Hey Michael - have to say - nice find mate and thanks for doubling down and showing how it can be reproduced.

Do you have a link to a mailing list post that we can follow the responses on?

[bug77]

Hm, almost all regressions are triggered by hackbench. That should help narrow things down.

[anarki2]

Curious to see SELinux benchmarks.

Given SELinux is much more in-depth and further reaching than AppArmor, I honestly expect it to be worst, but then it has more development so maybe not?

The difference is that Red Hat consists of actual developers while the Canonical crew seems like a bunch of script kiddies. In any case, I don't expect to see a great degree of slow down with unconfined contexts, which I assume most, if not all of the benchmarks would run under.

[Britoid]

The difference is that Red Hat consists of actual developers while the Canonical crew seems like a bunch of script kiddies. In any case, I don't expect to see a great degree of slow down with unconfined contexts, which I assume most, if not all of the benchmarks would run under.

I wouldn't quite put it like that, but yes Red Hat associated software tends to be engineered to a better level than Canonicals.

e.g. Snap vs Flatpak, Flatpak on a technical level absolutely wipes the floor over Snap. Canonicals technical choices have given sandboxed formats a bad name (e.g. slower startup), when apart from a fixed font issue, Flatpak doesn't really suffer from that problem.

systemd vs Upstart again, as controversial as it was, Poettering managed to one-man band make a better replacement for Upstart.

[finalzone]

The harsh truth about the so-called systemd vs upstart controversy is the unwillingness of Canonical to remove the clause licensing agreements having outside contributions kept for only Canonical. Systemd is basically what a redesigned Upstart should be.

[Volta]

The harsh truth about the so-called systemd vs upstart controversy is the unwillingness of Canonical to remove the clause licensing agreements having outside contributions kept for only Canonical. Systemd is basically what a redesigned Upstart should be.

Upstart had terrible service management. To disable service you had to edit text file.

[F.Ultra]

Upstart had terrible service management. To disable service you had to edit text file.

It also treated upstart-services and sysv-services as two completely different things, e.g when writing a upstart script one could not put in a dependency on a sysv service (Ubuntu never converted that many services over from sysv to upstart).