FreeBSD's Network Bridge Code Scores A 500% Performance Improvement

[Volta]

However, FreeBSD has the benefit of remiplementation: it can always avoid making the errors linux made. And linux is far from perfect.

That's true, but not always possible. Thanks to development power Linux can re implement even core stuff as well.

[wikinevick]

"most" in the sense that it is now possible to implement a variation of it ("epoch") without infringing on the ones that remain. Epoch *IS* a form of RCU, the difference between it and the Linux version(s) is in object reclamation rules. It makes no sense to say that epoch is better than RCU any more than that a synchronized{} block in Java is better than a mutex: it *is* a mutex. The Epoch implementation in FreeBSD is better in some ways than the one in Linux as it doesn't have nearly as many weird special cases and doesn't rely on too many "clever" tricks, on the other hand Linux is more efficient in scenarios with many readers and few writers. Besides both are constantly evolving.

FWIW, I cannot disclose whom but an implementation of RCU for FreeBSD was available. It was just never open sourced due to patent concerns.

[jacob]

I will agree with the first part of the claim. Linux has many more developers and SMP has always been ahead. However, FreeBSD has the benefit of remiplementation: it can always avoid making the errors linux made. And linux is far from perfect.

In this sense FreeBSD has the benefit of hindsight and that is certainly true. The ULE scheduler for example was inspired by Linux's previous O(1) scheduler but it also avoided some of its issues. Linux's advantage is not just in terms of more developers, but also the sheer brute force thrown at it. The Linux kernel is being benchmarked and profiled virtually 24/7/365 by teams all around the world. Yet FreeBSD stays competitive with a tiny fraction of the resources Linux development has and that is something.

[aht0]

In this sense FreeBSD has the benefit of hindsight and that is certainly true. The ULE scheduler for example was inspired by Linux's previous O(1) scheduler but it also avoided some of its issues. Linux's advantage is not just in terms of more developers, but also the sheer brute force thrown at it. The Linux kernel is being benchmarked and profiled virtually 24/7/365 by teams all around the world. Yet FreeBSD stays competitive with a tiny fraction of the resources Linux development has and that is something.

That same sheer brute force thrown at it breaks it way more often. Regressions of some kind or other are normality (not in a negative sense, just observing the fact - code base is large, complicated and it'd be hopeless task to veryify "everything" to the n-th degree against possible regressions for each new kernel version). In the end, it more or less balances out.

[aht0]

If I recall it right, if_bridge in FreeBSD used to be single-threaded by nature. Guess some devs finally wanted it replaced by multi-threaded code. In Linux it should scale more or less in a linear scale as you add threads (kind of remember relevant past benchmark by Michael here in Phoronix), it'd be interesting to see FreeBSD's if_bridge benches post-change.

[jacob]

That same sheer brute force thrown at it breaks it way more often. Regressions of some kind or other are normality (not in a negative sense, just observing the fact - code base is large, complicated and it'd be hopeless task to veryify "everything" to the n-th degree against possible regressions for each new kernel version). In the end, it more or less balances out.

Linux's code being larger and more complex that FreeBSD's and especially OpenBSD's is a factor, but I think the fact that regressions or bugs are indeed more frequent in Linux than in FreeBSD is mainly due to the fact that Linux is being used on a much broader range of hardware and architectures, for a much broader variety of workloads and applications. In production, 99% of FreeBSD deployments are basically file servers (NFS/SMB, HTTP, email...) of some sort and the OS is rarely if ever taken into uncharted territories. Linux is routinely used for file-type servers, but also on mobile phones, desktop workstations, set top boxes, embedded systems, supercomputers and everything else. Even though of the many architectures supported by Linux, only a few are actually relevant from a production point of view, in the real world the system is still expected to perform on Intel, ARM, POWER, MIPS and RiscV - that's probably more than what's asked of any other system in actual use and with commercial and technological pressures. That naturally leads to discovering many more bugs and cases of unexpected behavior, not to mention the permanent pressure to support the latest and greatest CPUs, GPUs etc., or to implement the Next Great Feature Of The Month(tm) that Company XYZ cannot live without. Ultimately both OSes are very good at achieving what they set as their goals, but those goals are quite different.

[aht0]

Linux's code being larger and more complex that FreeBSD's and especially OpenBSD's is a factor, but I think the fact that regressions or bugs are indeed more frequent in Linux than in FreeBSD is mainly due to the fact that Linux is being used on a much broader range of hardware and architectures, for a much broader variety of workloads and applications. In production, 99% of FreeBSD deployments are basically file servers (NFS/SMB, HTTP, email...) of some sort and the OS is rarely if ever taken into uncharted territories. Linux is routinely used for file-type servers, but also on mobile phones, desktop workstations, set top boxes, embedded systems, supercomputers and everything else. Even though of the many architectures supported by Linux, only a few are actually relevant from a production point of view, in the real world the system is still expected to perform on Intel, ARM, POWER, MIPS and RiscV - that's probably more than what's asked of any other system in actual use and with commercial and technological pressures. That naturally leads to discovering many more bugs and cases of unexpected behavior, not to mention the permanent pressure to support the latest and greatest CPUs, GPUs etc., or to implement the Next Great Feature Of The Month(tm) that Company XYZ cannot live without. Ultimately both OSes are very good at achieving what they set as their goals, but those goals are quite different.

"More code" equals "more bugs". Simple as that. It's something called "human factor". You cannot get entirely rid of it. Then, as complexity of the code grows, probability of the new errors will as well. Same problem with erasing chunks of old code, rewriting portions of code, any change might cause new bugs, rather unexpectedly. Sometimes new bug does not even express before some odd conditions have been met and so it could take a while before being found. Linux distros have, additional issue of it's "cobbled-together" nature - getting disparate parts of code work as unified whole and seemlessly is a bitch of a task. Companies also may manage to push through their hacky pieces of code, which would cause problems down the road. And so forth..

Mobile phones ain't Linux btw.. Android is distinct operating system. The fact that vendors have taken Linux kernel, modified it any which way and then are using it in their product does not make the Android running on devices automagically Linux.

I've seen washing machines and TV's coming with Berkeley licenses (meaning whatever they contain ain't embedded Linux). Pointless dickmeasuring.

[jacob]

"More code" equals "more bugs". Simple as that. It's something called "human factor". You cannot get entirely rid of it. Then, as complexity of the code grows, probability of the new errors will as well. Same problem with erasing chunks of old code, rewriting portions of code, any change might cause new bugs, rather unexpectedly. Sometimes new bug does not even express before some odd conditions have been met and so it could take a while before being found. Linux distros have, additional issue of it's "cobbled-together" nature - getting disparate parts of code work as unified whole and seemlessly is a bitch of a task. Companies also may manage to push through their hacky pieces of code, which would cause problems down the road. And so forth..

Mobile phones ain't Linux btw.. Android is distinct operating system. The fact that vendors have taken Linux kernel, modified it any which way and then are using it in their product does not make the Android running on devices automagically Linux.

I've seen washing machines and TV's coming with Berkeley licenses (meaning whatever they contain ain't embedded Linux). Pointless dickmeasuring.

Linux is Linux, plain and simple. It's the one and only software package called Linux, in other words the kernel. Nothing more, nothing less. Android uses Linux just like Debian uses Linux, there is nothing more to it. Linux bugs, if and when they arise, affect Android in the same way they affect Debian, Ubuntu or RHEL. In fact what is called "linux distros" are for the most part also distinct and separate operating systems.

The "cobbled together" nature of Linux distros is in fact largely a non-issue. It used to be "cobbled together" to some degree, but today most of the low level components including the systemd ecosystem, wayland and of course the package managers, including the new ones like flatpak and snap, are developed specifically with Linux in mind and for no other purpose. They are developed by separate teams under different names but it still forms and integrated system. In that regard recent versions of Ubuntu, Fedora or Debian are not all that different from FreeBSD.

As for dick measuring, there was and is no intention of dick measuring on my part. I was merely pointing out that Linux is used on a much greater variety of systems than FreeBSD and for a broader variety of applications, which is not "bigger" or "smaller" than yours, it's simply a matter of numbers. It means Linux needs a lot more code and features than virtually any other kernel in use, and it also means that Linux is much more likely to run into corner cases and thus expose bugs or implementation flaws. That's all.

[Steffo]

FreeBSD was always years behind Linux when comes to locking and SMP, so I doubt their implementation is in half as good as Linux RCU. I also doubt epoch is better:

http://csng.cs.toronto.edu/publicati...159/jpdc07.pdf

Are you kidding?! This paper is almost 14 years old!

[aht0]

Are you kidding?! This paper is almost 14 years old!

Its good enough for him, because it conveniently happens to support his particular bias towards Linux. Little questions like its currency can be thus disregarded.