In that example, I&#x27;m pretty sure forgoing containers and mlock would result in similar performance while using less memory. Process startup time would also be significantly improved. (If there&#x27;s such high contention for disk I&#x2F;O, reading 20GB on startup is going to take a <i>very</i> long time.)<p>The kernel&#x27;s page cache eviction strategy is smarter than naïve LRU. On the first read, a page is placed in the inactive file list. If it&#x27;s read again, it&#x27;s moved to the active file list. Pages in the inactive file list are purged before the active file list.[1] So large sequential reads may cause disk contention, but they won&#x27;t massacre the file cache.<p>This I&#x2F;O situation isn&#x27;t uncommon. Consumer systems also have big batch jobs that can pollute file caches: large copies, rsyncs, backup software (Déjà Dup, Time Machine, etc). They don&#x27;t solve this with containers, limits, and mlock()ing. Some programs add a couple calls to fadvise(), using the FADV_NOREUSE or FADV_DONTNEED flags.[2] But for the most part, doing nothing yields excellent performance. Operating systems are pretty good at their job.<p>1. <a href="https:&#x2F;&#x2F;www.kernel.org&#x2F;doc&#x2F;gorman&#x2F;html&#x2F;understand&#x2F;understand013.html" rel="nofollow">https:&#x2F;&#x2F;www.kernel.org&#x2F;doc&#x2F;gorman&#x2F;html&#x2F;understand&#x2F;understand...</a><p>2. This is handy for applications like bittorrent, where multiple reads of the same page are possible, but caching isn&#x27;t desired.