On Wed, Mar 11, 2020 at 04:53:17PM -0700, Shakeel Butt wrote: > On Wed, Mar 11, 2020 at 1:45 AM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > > On Tue 10-03-20 15:48:31, Dave Hansen wrote: > > > Maybe instead of just punting on MADV_PAGEOUT for map_count>1 we should > > > only let it affect the *local* process. We could still put the page in > > > the swap cache, we just wouldn't go do the rmap walk. > > > > Is it really worth medling with the reclaim code and special case > > MADV_PAGEOUT there? I mean it is quite reasonable to have an initial > > implementation that doesn't really touch shared pages because that can > > lead to all sorts of hard to debug and unexpected problems. So I would > > much rather go with a simple patch to check map count first and see > > whether somebody actually cares about those shared pages and go from > > there. > > > > Minchan, do you want to take my diff and turn it into the proper patch > > or should I do it. > > > > What about the remote_madvise(MADV_PAGEOUT)? Will your patch disable > the pageout from that code path as well for pages with mapcount > 1? Maybe, not because process_madvise syscall needs more previliedge(ie, PTRACE_MODE_ATTACH_FSCREDS) so I guess it would be more secure. So in that case, I want to rely on the LRU chance for shared pages. With that, the manager process could give a hint to several processes and finally makes them paging out. What do you think?