From: Minchan Kim <minchan@kernel.org> To: Michal Hocko <mhocko@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org>, linux-mm <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org>, linux-api@vger.kernel.org, Johannes Weiner <hannes@cmpxchg.org>, Tim Murray <timmurray@google.com>, Joel Fernandes <joel@joelfernandes.org>, Suren Baghdasaryan <surenb@google.com>, Daniel Colascione <dancol@google.com>, Shakeel Butt <shakeelb@google.com>, Sonny Rao <sonnyrao@google.com>, Brian Geffon <bgeffon@google.com>, jannh@google.com, oleg@redhat.com, christian@brauner.io, oleksandr@redhat.com, hdanton@sina.com Subject: Re: [RFCv2 5/6] mm: introduce external memory hinting API Date: Fri, 31 May 2019 23:11:43 +0900 Message-ID: <20190531141142.GA216592@google.com> (raw) In-Reply-To: <20190531140050.GS6896@dhcp22.suse.cz> On Fri, May 31, 2019 at 04:00:50PM +0200, Michal Hocko wrote: > On Fri 31-05-19 22:19:00, Minchan Kim wrote: > > On Fri, May 31, 2019 at 10:37:57AM +0200, Michal Hocko wrote: > > > On Fri 31-05-19 15:43:12, Minchan Kim wrote: > > > > There is some usecase that centralized userspace daemon want to give > > > > a memory hint like MADV_[COLD|PAGEEOUT] to other process. Android's > > > > ActivityManagerService is one of them. > > > > > > > > It's similar in spirit to madvise(MADV_WONTNEED), but the information > > > > required to make the reclaim decision is not known to the app. Instead, > > > > it is known to the centralized userspace daemon(ActivityManagerService), > > > > and that daemon must be able to initiate reclaim on its own without > > > > any app involvement. > > > > > > > > To solve the issue, this patch introduces new syscall process_madvise(2). > > > > It could give a hint to the exeternal process of pidfd. > > > > > > > > int process_madvise(int pidfd, void *addr, size_t length, int advise, > > > > unsigned long cookie, unsigned long flag); > > > > > > > > Since it could affect other process's address range, only privileged > > > > process(CAP_SYS_PTRACE) or something else(e.g., being the same UID) > > > > gives it the right to ptrace the process could use it successfully. > > > > > > > > The syscall has a cookie argument to privode atomicity(i.e., detect > > > > target process's address space change since monitor process has parsed > > > > the address range of target process so the operaion could fail in case > > > > of happening race). Although there is no interface to get a cookie > > > > at this moment, it could be useful to consider it as argument to avoid > > > > introducing another new syscall in future. It could support *atomicity* > > > > for disruptive hint(e.g., MADV_DONTNEED|FREE). > > > > flag argument is reserved for future use if we need to extend the API. > > > > > > Providing an API that is incomplete will not fly. Really. As this really > > > begs for much more discussion and it would be good to move on with the > > > core idea of the pro active memory memory management from userspace > > > usecase. Could you split out the core change so that we can move on and > > > leave the external for a later discussion. I believe this would lead to > > > a smoother integration. > > > > No problem but I need to understand what you want a little bit more because > > I thought this patchset is already step by step so if we reach the agreement > > of part of them like [1-5/6], it could be merged first. > > > > Could you say how you want to split the patchset for forward progress? > > I would start with new madvise modes and once they are in a shape to be > merged then we can start the remote madvise API. I believe that even > local process reclaim modes are interesting and useful. I haven't heard > anybody objecting to them without having a remote API so far. Okay, let's focus on [1-3/6] at this moment. > -- > Michal Hocko > SUSE Labs
next prev parent reply index Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-31 6:43 [RFCv2 0/6] introduce memory hinting API for external process Minchan Kim 2019-05-31 6:43 ` [RFCv2 1/6] mm: introduce MADV_COLD Minchan Kim 2019-05-31 8:47 ` Michal Hocko 2019-05-31 13:39 ` Minchan Kim 2019-05-31 14:03 ` Michal Hocko 2019-05-31 14:34 ` Minchan Kim 2019-06-03 7:16 ` Michal Hocko 2019-06-03 15:43 ` Daniel Colascione 2019-06-03 17:27 ` Johannes Weiner 2019-06-03 20:32 ` Michal Hocko 2019-06-03 21:50 ` Johannes Weiner 2019-06-03 23:02 ` Minchan Kim 2019-06-04 6:56 ` Michal Hocko 2019-06-04 12:06 ` Johannes Weiner 2019-06-04 6:55 ` Michal Hocko 2019-06-04 4:26 ` Minchan Kim 2019-06-04 7:02 ` Michal Hocko 2019-05-31 6:43 ` [RFCv2 2/6] mm: change PAGEREF_RECLAIM_CLEAN with PAGE_REFRECLAIM Minchan Kim 2019-05-31 6:43 ` [RFCv2 3/6] mm: introduce MADV_PAGEOUT Minchan Kim 2019-05-31 8:50 ` Michal Hocko 2019-05-31 13:44 ` Minchan Kim 2019-05-31 16:59 ` Johannes Weiner 2019-05-31 23:14 ` Minchan Kim 2019-05-31 6:43 ` [RFCv2 4/6] mm: factor out madvise's core functionality Minchan Kim 2019-05-31 7:04 ` Oleksandr Natalenko 2019-05-31 13:12 ` Minchan Kim 2019-05-31 14:35 ` Oleksandr Natalenko 2019-05-31 23:29 ` Minchan Kim 2019-06-05 13:27 ` Oleksandr Natalenko 2019-06-10 10:12 ` Minchan Kim 2019-05-31 6:43 ` [RFCv2 5/6] mm: introduce external memory hinting API Minchan Kim 2019-05-31 8:37 ` Michal Hocko 2019-05-31 13:19 ` Minchan Kim 2019-05-31 14:00 ` Michal Hocko 2019-05-31 14:11 ` Minchan Kim [this message] 2019-05-31 17:35 ` Daniel Colascione 2019-05-31 6:43 ` [RFCv2 6/6] mm: extend process_madvise syscall to support vector arrary Minchan Kim 2019-05-31 10:06 ` Yann Droneaud 2019-05-31 23:18 ` Minchan Kim
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=20190531141142.GA216592@google.com \ --to=minchan@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=bgeffon@google.com \ --cc=christian@brauner.io \ --cc=dancol@google.com \ --cc=hannes@cmpxchg.org \ --cc=hdanton@sina.com \ --cc=jannh@google.com \ --cc=joel@joelfernandes.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@kernel.org \ --cc=oleg@redhat.com \ --cc=oleksandr@redhat.com \ --cc=shakeelb@google.com \ --cc=sonnyrao@google.com \ --cc=surenb@google.com \ --cc=timmurray@google.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
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ linux-kernel@vger.kernel.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git