On 4/19/16 7:47 AM, dan_partelly wrote:

Look, take a look at history and the Linux kernel threads story and its
impact on FreeBSD.  If you'd like I can talk about it.

Please, yes, I would love to hear about it.
Sure, so back in late 90s, ~1999 sometime after Solaris released kernel threads Linux did as well.

It was pretty laughable, it was basically a hacked up version of fork that shared address space, files and a few other things and was horribly unstable and you couldn't use most of libc with it as there were many single-threaded deps in it.

It was so "laughably bad" that if you logged into a Linux system with threads and ran "top", it would look very strange as each thread had its own pid. So if you were running something like mysql it would look like you were forkbombed.

Now the point of all of this however was to get threads, and also to get threads that did well with disk IO.

FreeBSD at the time had threads, but they were "green threads" or "userland threads" which means they were super good for network IO, but nearly useless for disk IO.

This made Linux a much better platform for mysql, as mysql performed an order of magnitude better on Linux. In fact not only was FreeBSD slower, but in my experience it was buggier because the green threads implementation, while very cool, was complex and had its own share of bugs.

Some years passed and many people migrated to Linux to get the high performance mysql that was available on the platform.

Now during those years, as more and more people migrated away, FreeBSD had many, many, many, oh gosh, so many discussions on what to do about threads. So many opinions were had by so many people during which more people moved to Linux as a web platform... Not only were there opinions, but also implementations suggested, but those implementations were shot down in the search for the "one true threading system". Of course there were some loud folks that even insisted that threads were bad (and probably a phase) and we shouldn't even support them).

Luckily during that time (~2002) someone made this crazy "Linuxthreads" port which made """Linuxthreads""" available on FreeBSD, it had many of the same problems, but at least mysql was fast. Spoiler: The funny part about calling it "Linuxthreads" was that "Linuxthreads" wound up being the defacto way to do threads across *UNIX* because it was just simple and worked, should have just called it "realthreads" in my opinion. Luckily with the Linuxthreads port the die hards in the FreeBSD community who needed to run mysql for performance (or other software requiring real threads) could stay using FreeBSD while the community sorted out what exactly was to be done.

Places like Yahoo moved off of FreeBSD because they "just wanted threads" and if you tell someone to get "good performance with threads, then use Linuxthreads" (and of course make a grumpy face because "it's Linux") then they reason, "geez, why I am not just using Linux anyhow?" which they then migrate to.

So some years later (~2005) we went with a far more complex solution than needed called libkse. Libkse offered N:M threads, which didn't work very well for years due to complexity (hats off to those that *tried* to get it working in FreeBSD's political climate) to which finally Sun abandoned its N:M threads because they themselves could never get it right, and finally FreeBSD switched to 1:1 threads following Solaris. That was probably in 2007 timeline.

Now rewind to ~2001, about 2 years after the introduction of the sloppy, weird and strange kernel threads in Linux, and they had a pretty solid implementation. It wouldn't be until nearly 2009 when FreeBSD had a truly solid threads library and even now it suffers due to added complexity because we did things "smarter" than Linux.

Moral of the story? My takeaways from this story (and there are many similar ones in our recent history) are:

1) Graciously and rapidly accept steps forward and then contribute to them. Anything else leaves you stagnant and worse for wear.
2) Simple over complex.
3) If something someone else did is working for someone, then copy it and move on, don't waste a huge amount of your customer's time trying to make something better until you are sure that just copying it will not suffice.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to