Hacker News Reader

Comment by goodSyntax | Hacker News Reader

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.

View on HN

The 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.

Well, 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 ?

No - 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.

To 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.

> 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?

Universally. The kernel's page cache is the very last thing that a database operator wants.

I'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

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

Yes. Bypassing the kernel cache is a major optimization used by virtually all databases that are serious about prioritizing performance. It won't add anything to the top end of database engine performance.

However, there are plenty of databases that do not prioritize performance which could benefit, including most open source ones.

It is not as simple as that : https://www.pgcon.org/events/pgcon_2020/schedule/session/152...

FWIW, 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.

Reply on news.ycombinator.com