Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAG48ez0G3JkMq61gUmyQAaCq=_TwHbi1XKzWRooxZkv08PQKuw@mail.gmail.com>
 <20200310184814.GA8447@dhcp22.suse.cz> <CAG48ez2pNSKL9ZTH-PQ93+Kc6ObH6Pa1vVg3OS85WT0TB8m3=A@mail.gmail.com>
 <20200310210906.GD8447@dhcp22.suse.cz> <cf95db88-968d-fee5-1c15-10d024c09d8a@intel.com>
 <20200311084513.GD23944@dhcp22.suse.cz> <CALvZod6b73_ay_kxph143Aj+XBq04Np0z2bK4Rfn8qppihrmTw@mail.gmail.com>
 <20200312001849.GA96953@google.com> <CAKOZuev1XzbsCPJtOA=v9QMuVpEBKc0_5ZE4Oc4tzmKdFHy2Dg@mail.gmail.com>
In-Reply-To: <CAKOZuev1XzbsCPJtOA=v9QMuVpEBKc0_5ZE4Oc4tzmKdFHy2Dg@mail.gmail.com>
From:   Shakeel Butt <shakeelb@google.com>
Date:   Thu, 12 Mar 2020 08:15:42 -0700
Message-ID: <CALvZod6y87aJxq90p=99orPajxN30jOf_RohSw7OSRdrXg6-Ag@mail.gmail.com>
Subject: Re: interaction of MADV_PAGEOUT with CoW anonymous mappings?
To:     Daniel Colascione <dancol@google.com>
Cc:     Minchan Kim <minchan@kernel.org>, Michal Hocko <mhocko@kernel.org>,
        Dave Hansen <dave.hansen@intel.com>,
        Jann Horn <jannh@google.com>, Linux-MM <linux-mm@kvack.org>,
        kernel list <linux-kernel@vger.kernel.org>,
        "Joel Fernandes (Google)" <joel@joelfernandes.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Mar 11, 2020 at 7:04 PM Daniel Colascione <dancol@google.com> wrote:
>
> On Wed, Mar 11, 2020 at 5:18 PM Minchan Kim <minchan@kernel.org> wrote:
> >
> > 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@kernel.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?
> >
> > 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.
>
> I don't want the behavior of an madvise command to change depending on
> *how* the command is invoked. MADV_PAGEOUT should do the same thing
> regardless. If you want to allow purging of shared pages as well,
> please add a new MADV_PAGEOUT_ALL or something and require a privilege
> to use it.
>

I would like to have a way to pageout the shared pages and
MADV_PAGEOUT_ALL approach looks fine to me.