From: Daniel Colascione <firstname.lastname@example.org> To: Minchan Kim <email@example.com> Cc: Shakeel Butt <firstname.lastname@example.org>, Michal Hocko <email@example.com>, Dave Hansen <firstname.lastname@example.org>, Jann Horn <email@example.com>, Linux-MM <firstname.lastname@example.org>, kernel list <email@example.com>, "Joel Fernandes (Google)" <firstname.lastname@example.org> Subject: Re: interaction of MADV_PAGEOUT with CoW anonymous mappings? Date: Wed, 11 Mar 2020 19:03:29 -0700 Message-ID: <CAKOZuev1XzbsCPJtOA=v9QMuVpEBKc0_5ZE4Oc4tzmKdFHy2Dg@mail.gmail.com> (raw) In-Reply-To: <20200312001849.GA96953@google.com> On Wed, Mar 11, 2020 at 5:18 PM Minchan Kim <email@example.com> 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 <firstname.lastname@example.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.
next prev parent reply index Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-10 18:08 Jann Horn 2020-03-10 18:48 ` Michal Hocko 2020-03-10 19:11 ` Jann Horn 2020-03-10 21:09 ` Michal Hocko 2020-03-10 22:48 ` Dave Hansen 2020-03-11 8:45 ` Michal Hocko 2020-03-11 22:02 ` Minchan Kim 2020-03-11 23:53 ` Shakeel Butt 2020-03-12 0:18 ` Minchan Kim 2020-03-12 2:03 ` Daniel Colascione [this message] 2020-03-12 15:15 ` Shakeel Butt 2020-03-10 20:19 ` Daniel Colascione 2020-03-10 21:40 ` Jann Horn 2020-03-10 21:52 ` Daniel Colascione 2020-03-10 22:14 ` Minchan Kim 2020-03-12 8:22 ` Michal Hocko 2020-03-12 15:40 ` Vlastimil Babka 2020-03-12 20:16 ` Minchan Kim 2020-03-12 20:26 ` Dave Hansen 2020-03-12 20:41 ` Michal Hocko 2020-03-13 2:08 ` Minchan Kim 2020-03-13 8:05 ` Michal Hocko 2020-03-13 20:59 ` Minchan Kim 2020-03-16 9:20 ` Michal Hocko 2020-03-17 1:43 ` Minchan Kim 2020-03-17 7:12 ` Michal Hocko 2020-03-17 15:00 ` Minchan Kim 2020-03-17 15:58 ` Michal Hocko 2020-03-17 17:20 ` Minchan Kim 2020-03-12 21:41 ` Dave Hansen 2020-03-13 2:00 ` Minchan Kim 2020-03-13 16:59 ` Dave Hansen 2020-03-13 21:13 ` Minchan Kim 2020-03-12 23:29 ` Jann Horn
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAKOZuev1XzbsCPJtOA=v9QMuVpEBKc0_5ZE4Oc4tzmKdFHy2Dg@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-mm Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \ firstname.lastname@example.org public-inbox-index linux-mm Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kvack.linux-mm AGPL code for this site: git clone https://public-inbox.org/public-inbox.git