4 ms·
I don't see how this would be useful for people other than Google/Amazon/Microsoft because, to my uneducated self, it seems like their problem is driven by this
by goodSyntax 6y ago
I don't see how this would be useful for people other than Google/Amazon/Microsoft because, to my uneducated self, it seems like their problem is driven by this:
> Over the past decade of research and experimentation in memory overcommit, we observed a distinct trend across millions of servers and clients: the size of page cache has been decreasing because of the growing popularity of cloud storage. Nowadays anon pages account for more than 90% of our memory consumption and page cache contains mostly executable pages.
- jhalstead 6y agoFWIW, the Use Cases section presents data about the impact in mobile and laptop environments: On Android, our most advanced simulation that generates memory pressure from realistic user behavior shows 18% fewer low-memory kills, which in turn reduces cold starts by 16%. ... On Chrome OS, our field telemetry reports 96% fewer low-memory tab discards and 59% fewer OOM kills from fully-utilized devices and no UX regressions from underutilized devices.
- vinay_ys 6y agoThe implication of `growing popularity of cloud storage` is that today the user's data files are sitting in a remote cloud storage and not on local file system. This means a typical most-used application on user's Android/ChromeOS device (say a web browser, or a streaming app) has very little local file storage usage and hence very little page cache usage. Bulk of the memory is used by non-page-cache memory – that's anon memory. Based on this mix shift in memory use, this patchset is enhancing the swap system to evict anon pages better. It is useful for end-user linux devices like phones and laptops.
- ldng 6y agoWell, you are just confirming parent's affirmation. Not everybody uses the cloud. A database like PostgreSQL very much has local file storage usage and hence very high page cache usage. Or am I missing something ?
- refulgentis 6y agoNo - the post carefully lays out that client devices _also_ are dependent on anon page cache. Additionally, TFA has massive impressively statistics for client-side devices, as a cousin comment notes.
- ldng 6y agoTo me the TFA I've read says they've tested what is convenient for them: cloud compute node, chromebook (which are not desktop in the traditional sens) and phone. Which is fine since it suits their needs. But I maintain it needs more independant testing, on good-old-not-cloud-server, especially databases (which are not client-side devices). It may very well be that it is positive for that workoad too. Or not. That is all I'm saying.
- notriddle 6y ago> But I maintain it needs more independant testing, on good-old-not-cloud-server, especially databases Don't a lot of databases bypass the page cache for their payload data anyhow?
- jeffbee 6y agoUniversally. The kernel's page cache is the very last thing that a database operator wants.
- yuzhao 6y agoI'm one of the Google engineers who work on multigenerational LRU. The kernel page cache doesn't know better than databases themselves when it comes to what to cache. All high performance databases do this in user space, and they use AIO with direct IO or the latest io_uring to bypass the kernel page cache. Modern cloud (distributed) file systems do the same, including GFS: https://en.wikipedia.org/wiki/Google_File_System https://en.wikipedia.org/wiki/Google_File_System And speaking of io_uring, check this out to see how much improvement when copying without going through page cache: https://wheybags.com/blog/wcp.html https://wheybags.com/blog/wcp.html