On my server there're some running MEMCGs protected by memory.{min, low},
but I found the usage of these MEMCGs abruptly became very small, which
were far less than the protect limit. It confused me and finally I
found that was because of inode stealing.
Once an inode is freed, all its belonging page caches will be dropped as
well, no matter how may page caches it has. So if we intend to protect the
page caches in a memcg, we must protect their host (the inode) first.
Otherwise the memcg protection can be easily bypassed with freeing inode,
especially if there're big files in this memcg.
The inherent mismatch between memcg and inode is a trouble. One inode can
be shared by different MEMCGs, but it is a very rare case. If an inode is
shared, its belonging page caches may be charged to different MEMCGs.
Currently there's no perfect solution to fix this kind of issue, but the
inode majority-writer ownership switching can help it more or less.
This patchset contains five patches,
Patches 1-3: Minor opmizations and also the preparation of Patch-5
Patch 4: Preparation of Patch-5
Patch 5: the real issue I want to fix
- Changes against v1:
Use the memcg passed from the shrink_control, instead of getting it from
inode itself, suggested by Dave. That could make the laying better.
Yafang Shao (5):
mm, memcg: reduce size of struct mem_cgroup by using bit field
mm, memcg: introduce MEMCG_PROT_SKIP for memcg zero usage case
mm, memcg: reset memcg's memory.{min, low} for reclaiming itself
mm: make memcg visible to lru walker isolation function
memcg, inode: protect page cache from freeing inode
fs/inode.c | 25 ++++++++++++++--
include/linux/memcontrol.h | 54 ++++++++++++++++++++++++++++-------
mm/list_lru.c | 22 +++++++-------
mm/memcontrol.c | 71 +++++++++++++++++++++++++++++++++++-----------
mm/vmscan.c | 11 +++++++
5 files changed, 144 insertions(+), 39 deletions(-)
--
1.8.3.1
