Debian: kFreeBSD 9.0 Kernel Competing Against Linux 3.2

[kraftman]

And why would Debian care about how easy or hard is it for Ubuntu?

Maybe because Ubuntu propagates Debian's way when comes to few things like apt, debs. Ubuntu and Linux kernel (and kernel related things like systemd) are far more important for Debian than bsd crap. I don't like Debian cares about crap like kfreebsd and llvm as GCC replacement which just makes things more complicated. They're free to do what they want, but they do stupid things sometimes.

[mrugiero]

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.

And why would Debian care about how easy or hard is it for Ubuntu?

[vertexSymphony]

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

Whoops, sorry then ... I remember your postings in the mailing lists ( was it freebsd-hackers or freebsd-current? ) asking about a proper way of reading hardware data.

[vertexSymphony]

Different hardware? sorry, but this can't be called a benchmark ... or at least, you can't compare both stuff, *again*, when it came to comparing *BSD to a Linux, you did a bad developed benchmark.
Well, at least you didn't make the "mistake" of comparing ZFS vs ext4, and instead used ufs2

[Caesar Tjalbo]

Interesting benchmarks in itself but it feels meaningless:

Can you also perform the tests on identical hardware?

and identical filesystems? Not all the benchmarks appear to be a kernel-only test or am I wrong?

Some analysis as to what caused those huge differences in performance would be welcome.

Yes. I get it, the KFreeBSD kernel is generally slower but occasionally remarkably faster. Why? Were these results expected? Can you make the data accessible to noobs?

[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.

[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.

[Nobu]

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

[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?

[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.