Announcement
Collapse
No announcement yet.
Facebook Is Hiring To Make Linux Networking Better Than FreeBSD
Collapse
X
-
Originally posted by stevenc View PostAnd once upon a time there was Myspace, running Windows. That was over before it even got started...
Comment
-
Originally posted by Almindor View PostFreeBSD 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.
Comment
-
Originally posted by Pawlerson View PostThis 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.
Comment
-
Originally posted by xeekei View PostWhile 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.
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.
Comment
-
Originally posted by Almindor View PostFreeBSD 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.
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.
Comment
-
Originally posted by DebianLinuxero View PostI 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.
Comment
Comment