vmcache: Virtual-Memory Assisted Buffer Management [pdf]

cs.cit.tum.de

38 points·smasher164··4 comments

It's interesting that this paper, and even the one it references to blame the kernel - these groups don't seem to be interested in fixing kernel problems. Maybe it's just that there are more people doing research on the application level, and for them, working around the kernel makes more sense. Making changes that improve the kernel would have large knock-on benefits in other areas, but those are outside the groups' domain.

Tuning kswapd and shootdown would be worthwhile, especially since systems are getting dramatically fatter (even ignoring the appearance of low-latency storage).

> these groups don't seem to be interested in fixing kernel problems

I mean, they built a whole kernel module that addresses page allocation/deallocation scalability issues. Whether that gets brought upstream, I'm not sure.

Disclosure: I work in one of TUM's database groups.

From a researcher's perspective, upstream (Linux) kernel development is not attractive: it's a very time-consuming and lengthy process, often involving several iterations, which doesn't help with getting things done (i.e., PhD thesis and/or publications). Working around the kernel is much easier and, moreover, typically results in better performance, due to fewer context switches, better integration with the rest of the system, and more predictable behavior when running on other machines.

That said, some people in our group started looking into operating systems, but focus more on unikernels for cloud environments.

Well, it's not uncommon for apparently useful patch sets to be posted to lkml and just be ignored, even if they come from large companies and are posted many times. Given that kernel development seems to suffer from throughput bottlenecks, it makes sense that researchers ignore it.

Reply on news.ycombinator.com