[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALvZod6b73_ay_kxph143Aj+XBq04Np0z2bK4Rfn8qppihrmTw@mail.gmail.com>
Date: Wed, 11 Mar 2020 16:53:17 -0700
From: Shakeel Butt <shakeelb@...gle.com>
To: Michal Hocko <mhocko@...nel.org>
Cc: Dave Hansen <dave.hansen@...el.com>,
Minchan Kim <minchan@...nel.org>, Jann Horn <jannh@...gle.com>,
Linux-MM <linux-mm@...ck.org>,
kernel list <linux-kernel@...r.kernel.org>,
Daniel Colascione <dancol@...gle.com>,
"Joel Fernandes (Google)" <joel@...lfernandes.org>
Subject: Re: interaction of MADV_PAGEOUT with CoW anonymous mappings?
On Wed, Mar 11, 2020 at 1:45 AM Michal Hocko <mhocko@...nel.org> 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?
Powered by blists - more mailing lists