For servers running big data tools, like the one described, 99.99% of the IO is going to be from the application, so you want the IO algorithms tuned to that. If there is some inefficiency in the remaining 0.01% then too bad.

> The disadvantage, however, is that these algorithms are general-purpose and not tuned to the application.

Another big disadvantage is that the page cache is only useful for caching data of actual files and nothing else.

Do you mean you want to cache things that can't be serialised to memory pages, or you don't want the memory pages to be backed by files?

In the context of this article, many databases use the page cache to cache their data-structures, either in combination with private pages (ie postgres) or entirely (ie LMDB).

The latter case; and allocating anonymous memory is not caching.

Oh I see, I thought you might be referring to how the page cache (obviously) can't cache things like sockets.

Some applications do use the page cache for non-caching purposes though, for instance IPC, or ensuring their working-data will survive an application restart. The memory is still associated with files naturally, but this is often regarded as a feature, not a problem. Some applications use files on tmpfs so that their page cache data is backed by swap (or nothing), the same as anonymous pages.

All true in general, I imagine probably less relevant for Scylla though which is presumably tuned for running in a more dedicated setup.

Yes, good point, I was speaking in general terms. This article shows they've put a lot of thought into it and argues convincingly that bypassing the page cache makes sense for their system.