FreeBSD 7.0 Bests Linux In SMP Performance

cecom writes "After major improvements in SMP support in FreeBSD 7.0, benchmarks show it performing 15% better than the latest Linux kernels (PDF, see slides 17 to 19) on 8 CPUs under PostgreSQL and MySQL. While a couple of benchmarks are not conclusive evidence, it can be assumed that FreeBSD will once again be a serious performance contender. Some posters on LWN have noted that the level of Linux performance could be related to the Completely Fair Scheduler, which was merged into the 2.6.23 Linux kernel." Update: 03/06 21:32 GMT by KD : An anonymous reader sent in word that Linux kernel developer Nick Piggin reran the benchmark today and came to a different conclusion: In his benchmark Linux was faster than FreeBSD.

Re:You don't have to be Kreskin

[CastrTroy]

It probably has a lot to do with FreeBSD having a much more focused niche. FreeBSD is really tuned primarily for servers. You can use it on your desktop, but that's not really it's main purpose. Linux on the other hand, has really branched out. It has desktop distros, server distros, embedded distros, and probably a couple other areas I haven't thought of.

Bad news for Linux?

[Chrisq]

Since they switched to the Completely Fair Scheduler [wikipedia.org] to improve performance then it means one or two things. Either they have failed, as it seems to run slower than earlier Linux versions in the BSD test, or the tests that BSD chose are "untypical", maybe selected to show a particular advantage to BSD. I don't have the expertise to tell which, but I would be happier seeing some benchmarks from an independent source rather than BSD.

Re:Bad news for Linux?

[BitZtream]

Benchmarks are almost but not completely useless. In this particular setup, FBSD 7.0 runs postgres doing some specific set of queries faster than Linux.

Its a safe bet Linux will do some other set of things faster than FreeBSD does them, possibly even another specific set of PostgreSQL queries for that matter. Linux is definately more concerned with desktop app performance. I can say this safely because Linux actually cares about it, FreeBSD does not. Its there to serve, not run X. It will run X, and if they see a way to make performance better for the desktop apps AND the server apps, then it may go in the source tree. If its going to hurt the server side, don't bet on it.

While I use FreeBSD for my servers because its got a clean filesystem layout and is designed to be a server OS, I'd be willing to bet that someone with deep knowledge of PostgreSQL on Linux could give it a run for its money by tweaking the kernel for server performance.

Re:You don't have to be Kreskin

[CastrTroy]

How many of those packages are desktop packages? Seems like a odd metric to just compare the number of packages as to how well an OS is suited to the desktop.

Re:BSD Desktops

[Anonymous Coward]

FreeBSD is not fragmented like the 100 and 1 Linux distros

I'm a FreeBSD fan, but what kind of logic is that? You pick one example out of a fragmented set, and compare it to an entire other set of operating systems.

You act as if NetBSD, OpenBSD, DragonflyBSD, Darwin, etc, do not exist. Of course and item cannot be fragmented if if you define it's containing set as "itself". Makes about as much sense as:

Ubuntu is not fragmented like the 100 and 1 BSD distros

Re:You don't have to be Kreskin

[Klaus_1250]

I dunno, it seems to me that FreeBSD suits the desktop role really well

It does (I use it too) BUT only in specific environments. FreeBSD hardware support is not bad, but it is nowhere near as complete as that found in the various Linux distro's. My wireless keyboard + mouse is supported under any recent Linux distro, on FreeBSD, only the keyboard works (fixable with a unofficial ums.ko though). No support under FreeBSD for my DVB-C PCI card either.

Re:Well

[saleenS281]

You also wouldn't run Oracle or PostgreSQL on them unless you wanted to lose your job. The test is a great test for linux vs. freebds, because it's the type of environment where they'd compete.

Re:Bad news for Linux?

[Azarael]

The article is probably misleading (surprise, surprise), as the tuning documentation for PostgreSQL *states* that good IO performance has more of an impact than good CPU performance. Additionally, some other information I've read (search for postgres tuning/optimi(z|s)ation online) recommends FreeBSD because of its strong IO performance. I'll go out on a limb and assume that MySQL's performance attributes are similar.

In my opinion, the article summary is a pretty big red herring because the SMP performance may not have a huge impact on the result.

Re:Bad news for Linux?

[atomic-penguin]

For one, CFQ is not supposed to be an optimized I/O scheduler for database loads. That's where the Deadline scheduler comes in. You wouldn't want a "Fair" scheduler on your database server, as you would end up putting the database in I/O wait to handle lower priority processes.

Re:BSD Desktops

[BitZtream]

Of those you listed, Only DragonflyBSD and Darwin use a FreeBSD kernel, Darwin considerably modified, to the point that it might as well be counted on its own. You can not drop the FreeBSD kernel in any of them and have things work, except for Dragonfly, but even then it still requires (minor) modification.

Compare/Contrast to Linux distributions. The kernel, assuming version matchs, is rather interchangable between the distros. Its the file system layout, the utilities included, and default configurations that define the 'distro'.

With FreeBSD, all of the above is defined as 'FreeBSD'. DragonflyBSD is a fork it. As is PC-BSD and a couple of the even less known forks.

Linux distros are 'the GNU/Linux kernel' and 'the utilities and userland tools required to make it usable'.

Saying there are FreeBSD distros is like saying there are 'Slackware' distros, or some such variation. While I'm sure you could argue it, the meaning behind what we all consider it to be would be different than what people think of when its said.

Re:FreeBSD SMP threads + boehm-gc = totally broken

[Anonymous Coward]

boehm-gc is totally broken when using threads on FreeBSD SMP. And it's still totally broken on FreeBSD 7.

Strange, it's not listed as broken in the Ports tree:

http://www.freshports.org/devel/boehm-gc/ [freshports.org]
http://portsmon.freebsd.org/portoverview.py?category=devel&portname=boehm-gc [freebsd.org]

Have you contacted the MAINTAINER regarding your concerns, or filed a PR? If no one complains then no one will know to fix things. :)

Re:FreeBSD SMP threads + boehm-gc = totally broken

[Sancho]

Did you file a bug report and contact that port's maintainer?

Re:Seriously: who cares?

[mcrbids]

Compare 15% against Moore's law, and you find that it equates to a few weeks delay in the price-performance curve.

If it takes more than a few weeks to make the switch, you've already lost your benefit, as well as the potential of destabilizing your administration of those systems. Backups have be revisited, since the file tree will have changed. Network monitors will have to be updated, and tested for compatibility changes. Little one-off scripts to solve problem X or Y in a hurry will break. Admins will have to be trained, and will make more mistakes for a while until they find out what not to do. Unforeseen wrinkles will inevitably appear, Etc... Etc... Etc...

Worth it for Google? Not a chance!

Re:BSD Desktops

[Eivind Eklund]

I would count both Darwin and DragonflyBSD as their own kernels; they are substantially modified.

Eivind (ex/inactive FreeBSD kernel developer).

Re:You don't have to be Kreskin

[pajor]

What metric? Desktop drivers.

Re:Seriously: who cares?

[Cal Paterson]

Nobody living outside their parents' basement is going switch from Linux to BSD for a 15% performance increase. Somebody already using BSD might upgrade if the latest BSD kernels and environment are significantly better than past environments, but 15% is so slight as to be basically undetectable in a real-world environment!

Obviously, it depends on cost:benefit, which is exactly why there is no rule of thumb. Blanket generalisations and "rules of thumb" are a bad way of making a decision for everyone that they don't need to make

That isn't the important point though; the important point raised is that CFS might be less good than promised and that there's the accusation that Linus picked CFS over other projects because Ingo is in the in-crowd. I don't follow lkml, so I wouldn't know whether this is true.