Re: [RFC 6/7] mm: extend process_madvise syscall to support vector arrary
Thread information
[Search the linux-kernel archive]
[RFC 0/7] introduce memory hinting API for external process Minchan Kim ` [RFC 1/7] mm: introduce MADV_COOL Minchan Kim ` Michal Hocko ` Michal Hocko ` Suren Baghdasaryan ` Minchan Kim ` Minchan Kim ` Michal Hocko ` Minchan Kim ` Michal Hocko ` Minchan Kim ` [RFC 2/7] mm: change PAGEREF_RECLAIM_CLEAN with PAGE_REFRECLAIM Minchan Kim ` Johannes Weiner ` Minchan Kim ` [RFC 3/7] mm: introduce MADV_COLD Minchan Kim ` Michal Hocko ` Minchan Kim ` Michal Hocko ` Minchan Kim ` Minchan Kim ` [RFC 4/7] mm: factor out madvise's core functionality Minchan Kim ` Oleksandr Natalenko ` Minchan Kim ` Oleksandr Natalenko ` Michal Hocko ` Oleksandr Natalenko ` Minchan Kim ` Michal Hocko ` Minchan Kim ` Michal Hocko ` Minchan Kim ` Michal Hocko ` [RFC 5/7] mm: introduce external memory hinting API Minchan Kim ` Michal Hocko ` Minchan Kim ` Michal Hocko ` Minchan Kim ` Christian Brauner ` Minchan Kim ` Christian Brauner ` Oleg Nesterov ` Minchan Kim ` Oleg Nesterov ` Minchan Kim ` Michal Hocko ` Minchan Kim ` [RFC 6/7] mm: extend process_madvise syscall to support vector arrary Minchan Kim ` Michal Hocko ` Minchan Kim ` Michal Hocko [this message] ` Minchan Kim ` Michal Hocko ` Minchan Kim ` Daniel Colascione ` Michal Hocko ` Minchan Kim ` Michal Hocko ` Minchan Kim ` Daniel Colascione ` Michal Hocko ` Minchan Kim ` [RFC 7/7] mm: madvise support MADV_ANONYMOUS_FILTER and MADV_FILE_FILTER Minchan Kim ` Michal Hocko ` Minchan Kim ` Michal Hocko ` Minchan Kim ` Michal Hocko ` Minchan Kim ` Michal Hocko ` Minchan Kim ` Daniel Colascione ` Minchan Kim ` Michal Hocko ` Daniel Colascione ` Michal Hocko ` Daniel Colascione ` Michal Hocko ` Daniel Colascione ` Michal Hocko ` Minchan Kim ` Michal Hocko ` Minchan Kim ` Michal Hocko ` Daniel Colascione ` Michal Hocko ` Daniel Colascione ` Michal Hocko ` Minchan Kim ` Minchan Kim ` Daniel Colascione ` Michal Hocko ` Minchan Kim ` Daniel Colascione ` Johannes Weiner ` Minchan Kim ` Minchan Kim ` [RFC 0/7] introduce memory hinting API for external process Anshuman Khandual ` Tim Murray ` Anshuman Khandual ` Minchan Kim ` Michal Hocko ` Anshuman Khandual ` Shakeel Butt ` Brian Geffon ` Michal Hocko ` Oleksandr Natalenko ` Minchan Kim ` Johannes Weiner ` Minchan Kim ` Michal Hocko ` Matthew Wilcox ` Minchan Kim ` Michal Hocko ` Christian Brauner ` Minchan Kim ` Christian Brauner ` Christian Brauner ` Daniel Colascione ` Christian Brauner ` Daniel Colascione ` Christian Brauner ` Daniel Colascione ` Christian Brauner ` Daniel Colascione ` Christian Brauner ` Daniel Colascione ` Minchan Kim ` Minchan Kim ` Minchan Kim ` Christian Brauner ` Oleksandr Natalenko ` Shakeel Butt
| From: | Michal Hocko <mhocko-AT-kernel.org> | |
| To: | Minchan Kim <minchan-AT-kernel.org> | |
| Subject: | Re: [RFC 6/7] mm: extend process_madvise syscall to support vector arrary | |
| Date: | Tue, 21 May 2019 08:24:21 +0200 | |
| Message-ID: | <20190521062421.GD32329@dhcp22.suse.cz> | |
| Cc: | Andrew Morton <akpm-AT-linux-foundation.org>, LKML <linux-kernel-AT-vger.kernel.org>, linux-mm <linux-mm-AT-kvack.org>, Johannes Weiner <hannes-AT-cmpxchg.org>, Tim Murray <timmurray-AT-google.com>, Joel Fernandes <joel-AT-joelfernandes.org>, Suren Baghdasaryan <surenb-AT-google.com>, Daniel Colascione <dancol-AT-google.com>, Shakeel Butt <shakeelb-AT-google.com>, Sonny Rao <sonnyrao-AT-google.com>, Brian Geffon <bgeffon-AT-google.com>, linux-api-AT-vger.kernel.org |
On Tue 21-05-19 11:48:20, Minchan Kim wrote: > On Mon, May 20, 2019 at 11:22:58AM +0200, Michal Hocko wrote: > > [Cc linux-api] > > > > On Mon 20-05-19 12:52:53, Minchan Kim wrote: > > > Currently, process_madvise syscall works for only one address range > > > so user should call the syscall several times to give hints to > > > multiple address range. > > > > Is that a problem? How big of a problem? Any numbers? > > We easily have 2000+ vma so it's not trivial overhead. I will come up > with number in the description at respin. Does this really have to be a fast operation? I would expect the monitor is by no means a fast path. The system call overhead is not what it used to be, sigh, but still for something that is not a hot path it should be tolerable, especially when the whole operation is quite expensive on its own (wrt. the syscall entry/exit). I am not saying we do not need a multiplexing API, I am just not sure we need it right away. Btw. there was some demand for other MM syscalls to provide a multiplexing API (e.g. mprotect), maybe it would be better to handle those in one go? -- Michal Hocko SUSE Labs