Autonomously Finding Performance Regressions In The Linux Kernel

[phoronix]

Phoronix: Autonomously Finding Performance Regressions In The Linux Kernel

Last weekend a few Phoronix benchmarks were underway of the Linux 2.6.32-rc5 kernel when a very significant performance regression was spotted. This regression caused the PostgreSQL server to run at about 18% of the performance found in earlier kernel releases. Long story short, in tracking down this performance regression we have finally devised a way to autonomously locate performance regressions within the Linux kernel and potentially any Git-based project for that matter. Here are a few details.

http://www.phoronix.com/vr.php?view=14285

[BlackStar]

Very nice, PTS is getting better and better!

[droidhacker]

Amazing.
That this thing could actually be used to do something *useful*

[Apopas]

Terrific idea!

[rehabdoll]

rc-5 was a dog. caused some nice fs-corruption on my /

[pvtcupcakes]

So this would be completely automatic? Meaning you could go out to lunch and not be anywhere near the machine while PTS tracks down the regression?

Originally Posted by rehabdoll

rc-5 was a dog. caused some nice fs-corruption on my /

Seemed to happen to me in rc4 as well. I use Gentoo, and I booted up one day and my /etc/profile.env got all messed up somehow. After fixing that from a livecd, I booted up again and ended up with a hole bunch of corruption, and lost a bunch of files. Pidgin preferences, /etc/portage/package.use, some KDE configuration stuff, etc. Oh and I lost my world file, so Portage forgot all the packages I had installed.

[Michael]

Originally Posted by pvtcupcakes

So this would be completely automatic? Meaning you could go out to lunch and not be anywhere near the machine while PTS tracks down the regression?

Yes, that is how it works in PTS Bardu 2.2.

[mirza]

Wait, this means that if I want to have consistent data on ext4 I must look at 5x slower PostgreSQL and other write-intensive applications? And proposed solution is either obscure mount switch with possibility of occasional file corruption or really _slow_ PostgreSQL. WTF?

[myxiplx]

Wow, just wow.

I'm no programmer, but this is an amazing piece of work. I can see this being an invaluable tool.

[JeanPaul145]

Originally Posted by mirza

Wait, this means that if I want to have consistent data on ext4 I must look at 5x slower PostgreSQL and other write-intensive applications? And proposed solution is either obscure kernel switch with possibility of occasional file corruption or really _slow_ PostgreSQL. WTF?

I was thinking the same thing. I think I'll stick with Ext3 for now
(I have had Ext4 corruption before, so I simply don't trust the fs).