Debian: kFreeBSD 9.0 Kernel Competing Against Linux 3.2

[phoronix]

Phoronix: Debian: kFreeBSD 9.0 Kernel Competing Against Linux 3.2

The Debian GNU/kFreeBSD project has been quite interesting as one of the official Debian operating system ports. Debian GNU/kFreeBSD pairs the FreeBSD kernel with the Debian GNU user-land so that users can enjoy their traditional Debian applications while taking advantage of the FreeBSD kernel. With the recently released FreeBSD 9.0 kernel having worked its way into Debian Wheezy, how is the FreeBSD 9.0 kernel performance compared to the Linux 3.2 kernel? This article provides those benchmarks.

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

[elanthis]

Some analysis as to what caused those huge differences in performance would be welcome. Especially as, to my knowledge, several of those were just CPU-bound tests that should have relatively little impact from the kernel in use, unless there's something pathologically wrong with the CPU scheduler or memory manager subsystems of the kernel. I mean, I'd expect there to potentially be huge differences in I/O throughput or something that's heavily dependent on the kernel's algorithms of choice, but not for something that is mostly a test of the system's hardware.

[BagOfMostlyWater]

Can you also perform the tests on identical hardware?

[Nobu]

Processor:
 - Debian kFreeBSD:	AMD Opteron 2384 @ 2.70GHz (8 Cores)
 - Debian Linux:	2 x AMD Opteron 2384 @ 2.70GHz (8 Cores)

Really? Is this right? Am I seeing things?

[Michael]

Can you also perform the tests on identical hardware?

The tests were done on the same hardware.... There's reporting differences between the kernels.

[Michael]

Processor:
 - Debian kFreeBSD:    AMD Opteron 2384 @ 2.70GHz (8 Cores)
 - Debian Linux:    2 x AMD Opteron 2384 @ 2.70GHz (8 Cores)

Really? Is this right? Am I seeing things?

Ditto. Same hardware, but Debian GNU/kFreeBSD doesn't properly expose multiple sockets for PTS to read.

[DeepDayze]

Ditto. Same hardware, but Debian GNU/kFreeBSD doesn't properly expose multiple sockets for PTS to read.

Sounds like a bug or something not properly implemented in the kFreeBSD kernel..perhaps a good idea to report this upstream and see what response you get?

[Nobu]

Phew, I was starting to think Michael had gotten some serious server hardware...as if eight cores isn't already pretty serious.

[kraftman]

I hope Debian will get rid of kfreebsd kernel and simply focus on Linux and systemd, so it will be easier to Ubuntu to switch. The benchmark results are great. It's good to see the same GCC version was used.

[Shining Arcanine]

Some analysis as to what caused those huge differences in performance would be welcome. Especially as, to my knowledge, several of those were just CPU-bound tests that should have relatively little impact from the kernel in use, unless there's something pathologically wrong with the CPU scheduler or memory manager subsystems of the kernel. I mean, I'd expect there to potentially be huge differences in I/O throughput or something that's heavily dependent on the kernel's algorithms of choice, but not for something that is mostly a test of the system's hardware.

I doubt soft updates was enabled on UFS. Also, I suspect that the NAS parallel benchmarks are likely showing some sort of configuration issue. CG.B for instance is exactly half that of Linux. Nobu's comment about the kFreeBSD system having only 1 socket available to it could be correct.