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.
That said, it's interesting to have this kind of thing come out of large-scale production web environments in China.
>on Linux 2.6.32 achieves 470K connection per second and 83% efficiency up to 24 cores, while performance of base 2.6.32 kernel increases non-linearly up to 12 cores and drops dramatically to 159K with 24 cores. The latest 3.13 kernel doubles the throughput to 283K when using 24 cores compared with 2.6.32. However, it has not completely solve the scalability bottlenecks, preventing performance from growing when more than 12 cores are used.
It's actually not that kernel. It's the CentOS kernel, which is the RedHat kernel, which was based on a 2.6 kernel years ago, but has since had every single kernel change under the sun backported to it. It might as well be RedHat's version of 3.10. This is also why it's a bad idea to build any kernel patches on top of RedHat kernels: it has nothing to do with the vanilla trees.
In any case, it doesn't matter if it's a 50 year old kernel. If it speeds up connections per second, someone will put up a box on the frontend with it as the load balancer.
Is it possible that by using an old kernel like this one, you'd expose yourself to security vulnerabilities?
I'm new to kernel programming. Is this submission suggesting that you downgrade your kernel to a 2010-era release in order to take advantage of the performance improvements, or is the submission showing some kind of modular component which you can integrate into your current kernel?
If it's the former, then wouldn't you be pinning yourself to the old version of the kernel, so you'll have to integrate all updates by hand rather than receive them automatically during the normal update process?
This kernel is what Red Hat Enterprise Linux 6 is currently using. Red Hat maintains it, and writes patches for security vulnerabilities. It's no surprise that Sina developed, tested, and deployed this patch against what they were running in production.
By using this kernel, will you be able to automatically receive security upgrades in the future? Or will you have to apply them manually and then recompile and install the kernel yourself?
Is "developers have to apply security patches manually, then recompile and reinstall the kernel themselves rather than automatically" not a big deal in practice?
It's not a big deal, because you can automate it. As long as the patch applies cleanly (and it almost certainly will if the only vendor changes are security updates), it's going to be a pretty smooth process.
You'd need to test the new kernel before deploying in production, of course, but you'd be doing that before rolling out a vendor provided kernel change, anyway.
Old kernel perhaps, but that's still what's being shipped with the latest CentOS6 (and by extension, RHEL 6 as well). Old as it might be, it's in very wide use.
This would be a tremendous boon for those environments!
The openssl 0.9.8 with Apache/2.2.3 combo only supports TLS 1.0. I couldn't setup TLS to get better than grade "B" on Qualys' SSL Server Test. I sacrificed MSIE on WinXP, used TLS 1.0 only, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA only, got a "B". I want Forward Secrecy only, AEAD only setup. Have to upgrade to RHEL6 for that.
That said, it's interesting to have this kind of thing come out of large-scale production web environments in China.