The performance data looks interesting, but this is work based on a pretty old kernel (originally released in 2010 or so). There have been many changes and improvements added to the 3.x kernel that may overlap with this work. Publishing the code and details on github is great, but working with the kernel community and merging into the mainstream kernel is the only way for work like this to have a long-term meaningful existence - Google in particular have been doing a great job getting networking improvements in.<p>That said, it's interesting to have this kind of thing come out of large-scale production web environments in China.
Looks like its based on 2.6.32 series. I would hope they start working with the upstream Kernel otherwise this project will stay stuck in Limbo as previous initiatives to improve TCP handling at kernel level (e.g: Megapipe).<p>This version do not support TCP_FASTOPEN, SO_REUSEPORT, TCP_AUTOCORKING, etc.
Why would the evaluation charts look the way they do?<p><a href="https://github.com/fastos/fastsocket#online-evaluation" rel="nofollow">https://github.com/fastos/fastsocket#online-evaluation</a><p>The "before and after" CPU series have nearly the same exact fit. If the data was from separate 24 hour periods, wouldn't you expect the graphs to look different? I recognize that with a large service, you'd get repetitive load patterns, but the similarity here look a little extreme.