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.
-Alfred
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
