[HN Gopher] vmcache: Virtual-Memory Assisted Buffer Management [...
___________________________________________________________________
vmcache: Virtual-Memory Assisted Buffer Management [pdf]
Author : smasher164
Score : 31 points
Date : 2023-12-31 11:44 UTC (1 days ago)
(HTM) web link (www.cs.cit.tum.de)
(TXT) w3m dump (www.cs.cit.tum.de)
| markhahn wrote:
| 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).
| smasher164 wrote:
| > 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.
| aengelke wrote:
| 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.
___________________________________________________________________
(page generated 2024-01-01 23:01 UTC)