On Tue 06-04-21 22:34:02, Neil Sun wrote: > > > On 2021/4/6 19:39, Michal Hocko wrote: > > On Tue 06-04-21 19:30:22, Neil Sun wrote: > > > On 2021/4/6 15:21, Michal Hocko wrote: > > > > > > > > You are changing semantic of the existing user interface. This knob has > > > > never been memcg aware and it is supposed to have a global impact. I do > > > > not think we can simply change that without some users being surprised > > > > or even breaking them. > > > > > > Yes, do you think add new interface to sysfs is a good way? such as > > > /sys/fs/cgroup/memory/lxc/i-vbe1u8o7/memory.kmem.drop_caches > > > > There were other attempts to add a memcg specific alternative to > > drop_caches. A lack of a strong usecase has been a reason that no such > > attempt has been merged until now. drop_caches is a problematic > > interface because it is really coarse and people have learned to (ab)use > > it to workaround problem rather than fix them properly. > > > > What is your usecase? > > > > We have some lxc containers running on the server, when mysqld running > backup jobs in the container, page cache will grow up and eat up all unused > memory in the container, then some new jobs come, we can see that tasks are > busy on allocing memory with reclaiming, so we want to drop page cache after > mysql backup job for individual container, it will speed up allocing memory > when new jobs come. > > This patch only drop slab cache but not page cache, this can be the > first step if people really need this interface. Have you considered using high limit for the pro-active memory reclaim? It really seems odd to drop a certain category of memory without aging information we already do have. I do understand the start time overhead concern but it seems to be a much better approach to drop old objects rather than hammer a very specific type of memory. -- Michal Hocko SUSE Labs
