The Use Case
============
We have a scenario where multiple services (cgroups) may share the same
file cache, as illustrated below:
download-proxy application
\ /
/shared_path/shared_files
When the application needs specific types of files, it sends an RPC request
to the download-proxy. The download-proxy then downloads the files to
shared paths, after which the application reads these shared files. All
disk I/O operations are performed using buffered I/O.
The reason for using buffered I/O, rather than direct I/O, is that the
download-proxy itself may also read these shared files. This is because it
serves as a peer-to-peer (P2P) service:
download-proxy of server1 <- P2P -> download-proxy of server2
/shared_path/shared_files /shared_path/shared_files
The Problem
===========
Applications reading these shared files may use mlock to pin the files in
memory for performance reasons. However, the shared file cache is charged
to the memory cgroup of the download-proxy during the download or P2P
process. Consequently, the page cache pages of the shared files might be
mlocked within the download-proxy's memcg, as shown:
download-proxy application
| /
(charged) (mlocked)
| /
pagecache pages
\
\
/shared_path/shared_files
This setup leads to a frequent scenario where the memory usage of the
download-proxy's memcg reaches its limit, potentially resulting in OOM
events. This behavior is undesirable.
The Solution
============
To address this, we propose introducing a new cgroup file, memory.nomlock,
which prevents page cache pages from being mlocked in a specific memcg when
set to 1.
Implementation Options
----------------------
- Solution A: Allow file caches on the unevictable list to become
reclaimable.
This approach would require significant refactoring of the page reclaim
logic.
- Solution B: Prevent file caches from being moved to the unevictable list
during mlock and ignore the VM_LOCKED flag during page reclaim.
This is a more straightforward solution and is the one we have chosen.
If the file caches are reclaimed from the download-proxy's memcg and
subsequently accessed by tasks in the application’s memcg, a filemap
fault will occur. A new file cache will be faulted in, charged to the
application’s memcg, and locked there.
Current limitations
==================
This solution is in its early stages and has the following limitations:
- Timing Dependency:
memory.nomlock must be set before file caches are moved to the
unevictable list. Otherwise, the file caches cannot be reclaimed.
- Metrics Inaccuracy:
The "unevictable" metric in memory.stat and the "Mlocked" metric in
/proc/meminfo may not be reliable. However, these metrics are already
affected by the use of large folios.
If this solution is deemed acceptable, I will proceed with refining the
implementation and addressing these limitations.
Yafang Shao (2):
mm/memcontrol: add a new cgroup file memory.nomlock
mm: Add support for nomlock to avoid folios beling mlocked in a memcg
include/linux/memcontrol.h | 3 +++
mm/memcontrol.c | 35 +++++++++++++++++++++++++++++++++++
mm/mlock.c | 9 +++++++++
mm/rmap.c | 8 +++++++-
mm/vmscan.c | 5 +++++
5 files changed, 59 insertions(+), 1 deletion(-)
--
2.43.5
