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>
In-Reply-To: <20200312001849.GA96953@google.com>
From:   Daniel Colascione <dancol@google.com>
Date:   Wed, 11 Mar 2020 19:03:29 -0700
Message-ID: <CAKOZuev1XzbsCPJtOA=v9QMuVpEBKc0_5ZE4Oc4tzmKdFHy2Dg@mail.gmail.com>
Subject: Re: interaction of MADV_PAGEOUT with CoW anonymous mappings?
To:     Minchan Kim <minchan@kernel.org>
Cc:     Shakeel Butt <shakeelb@google.com>,
        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 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.

> With that, the manager process could give a hint to several processes
> and finally makes them paging out.

On many different occasions over the past few years, I've found myself
wanting to ask the kernel to do bulk memory management operations. I'd
much rather add *one* facility to allow for multiple-target mm
operations than add one-off special cases for specific callers cases
as they come up. If we had such a bulk operation, the kernel could
inspect the bulk operation payload, see whether the number of
MADV_PAGEOUT requests for a given page were equal to the share count
for that page, and, if so, evict that page despite it being shared.