Facebook Is Hiring To Make Linux Networking Better Than FreeBSD

[EGOvoruhk]

I thought BSD and Facebook were dead?

WAT??

[stevenc]

I thought BSD and Facebook were dead?

And once upon a time there was Myspace, running Windows. That was over before it even got started...

[Michael_S]

And once upon a time there was Myspace, running Windows. That was over before it even got started...

Be fair - everything that killed MySpace had to do with the user interface and the auto-play audio feature, and very little to do with Windows. Linux or FreeBSD would not have saved them from their 1997 Geocities interface.

[Guest]

Side effect: FB would no longer need to work on btrfs because FreeBSD has great ZFS support out of the box.

As you should already notice they have chosen Linux over FreeBSD.

[Guest]

FreeBSD is better on the network stack. I should know since I coded a networking library to use the best possible non-blocking mechanism on various OSes.

Just for a specific comparison, freeBSD has kQueue where Linux has epoll mechanism. Both are replacements for the ancient select call which is extremely inefficient when there's a huge amount of connections (see C10k problem).

kQueue is very smart in how it reports events happening on sockets and gives you the full list of "read" and "write" events in one go. That means one syscall/gateway per report batch in a scheduled slice.

epoll on the other hand can only report reads or writes in one syscall/gateway. The way to have "one" event reporting point with epoll is to epoll two epolls on top one for reads one for writes, which means it can go up to 3 syscalls. That IS 3x slower on linux, I have tested this.

This is just one part of the problem, I'm guessing they have other, deeper issues. I think it'd help if fanboys who know nothing of the systems stopped being so defensive.

This is just example from Berkeleys paper. If you really know something you wouldn't just copy paste from it. If this is just one part of the problem I'm waiting to hear about others.

[Michael_S]

This is just example from Berkeleys paper. If you really know something you wouldn't just copy paste from it. If this is just one part of the problem I'm waiting to hear about others.

From the job posting, "Our goal over the next few years is for the Linux kernel network stack to rival or exceed that of FreeBSD." That seems to indicate that at least someone with some clout at Facebook thinks that FreeBSD trumps Linux for networking, and since it's a general statement I will guess - I admit, it's just a guess - that whatever the difference is, it's more than just epoll vs. kqueue.

[xeekei]

While you guys throw fanboy poop at each other, all I have to say is: thank you Facebook for contributing to open source software. It'll be interesting to see what comes out of this effort.

[DebianLinuxero]

While you guys throw fanboy poop at each other, all I have to say is: thank you Facebook for contributing to open source software. It'll be interesting to see what comes out of this effort.

I wonder what license will use the code contributed by Facebook.

The ideal is pure GPL3, but you know how this big companies think.

In the end they don't like to contribute to the community the same way they were beneficiated by.

So I spect a nasty license or a GPL3 dual with some other in-house monster, ala Canonical.

[Yoshman]

FreeBSD is better on the network stack. I should know since I coded a networking library to use the best possible non-blocking mechanism on various OSes.

Just for a specific comparison, freeBSD has kQueue where Linux has epoll mechanism. Both are replacements for the ancient select call which is extremely inefficient when there's a huge amount of connections (see C10k problem).

kQueue is very smart in how it reports events happening on sockets and gives you the full list of "read" and "write" events in one go. That means one syscall/gateway per report batch in a scheduled slice.

epoll on the other hand can only report reads or writes in one syscall/gateway. The way to have "one" event reporting point with epoll is to epoll two epolls on top one for reads one for writes, which means it can go up to 3 syscalls. That IS 3x slower on linux, I have tested this.

This is just one part of the problem, I'm guessing they have other, deeper issues. I think it'd help if fanboys who know nothing of the systems stopped being so defensive.

It is true that you cannot add/delete/modify the state of descriptors in batch with epoll, but epoll has no problem reporting status of multiple descriptors, both their read and write status, with a single system call (epoll_wait()).

One have to re-arm(if using EPOLLONESHOT) / modify (if something need to be change for the descriptor) each file-descriptor one-by-one using epoll_ctl(). A batch call for re-arming would be a good thing but it is less useful than one think as most software tend to be written to deal with one file-descriptor event at a time so it is most natural to include re-arming in that event processing.

kqueue is more powerful, but epoll is not really as far behind as you say and if you got x3 worse performance then there is definitely optimization potential in your epoll logic to be done. Assume every socket result in a read/write cycle, a single call would report N ready descriptors, a total of 2*N calls is made for read/write, epoll requires N calls in the end kqueue could do with 1.

So the ratio in the example is (1 + 2*N + N) / (1 + 2*N + 1) = (1 + 3*N) / (2 + 2*N) ~ x1.5 for large N and less if more system calls are made on a per event basis.

[xeekei]

I wonder what license will use the code contributed by Facebook.

The ideal is pure GPL3, but you know how this big companies think.

In the end they don't like to contribute to the community the same way they were beneficiated by.

So I spect a nasty license or a GPL3 dual with some other in-house monster, ala Canonical.

Probably not, since only GPLv2 code gets accepted into the kernel. All you needed to do was look at Facebook's past projects before posting. Google "HipHop PHP".