On Fri 31-07-20 09:50:04, Yafang Shao wrote: > On Thu, Jul 30, 2020 at 7:26 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > On Tue 28-07-20 03:40:32, Yafang Shao wrote: > > > Sometimes we use memory.force_empty to drop pages in a memcg to work > > > around some memory pressure issues. When we use force_empty, we want the > > > pages can be reclaimed ASAP, however force_empty reclaims pages as a > > > regular reclaimer which scans the page cache LRUs from DEF_PRIORITY > > > priority and finally it will drop to 0 to do full scan. That is a waste > > > of time, we'd better do full scan initially in force_empty. > > > > Do you have any numbers please? > > > > Unfortunately the number doesn't improve obviously, while it is > directly proportional to the numbers of total pages to be scanned. Your changelog claims an optimization and that should be backed by some numbers. It is true that reclaim at a higher priority behaves slightly and subtly differently but that urge for even more details in the changelog. > But then I notice that force_empty will try to write dirty pages, that > is not expected by us, because this behavior may be dangerous in the > production environment. I do not understand your claim here. Direct reclaim doesn't write dirty page cache pages directly. And it is even less clear why that would be dangerous if it did. > What do you think introducing per memcg drop_cache ? I do not like the global drop_cache and per memcg is not very much different. This all shouldn't be really necessary because we do have means to reclaim memory in a memcg. -- Michal Hocko SUSE Labs
