From: Oleksandr Natalenko <oleksandr@redhat.com> To: Minchan Kim <minchan@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org>, LKML <linux-kernel@vger.kernel.org>, linux-mm <linux-mm@kvack.org>, Michal Hocko <mhocko@suse.com>, 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> Subject: Re: [RFC 4/7] mm: factor out madvise's core functionality Date: Mon, 20 May 2019 16:26:33 +0200 [thread overview] Message-ID: <20190520142633.x5d27gk454qruc4o@butterfly.localdomain> (raw) In-Reply-To: <20190520035254.57579-5-minchan@kernel.org> Hi. On Mon, May 20, 2019 at 12:52:51PM +0900, Minchan Kim wrote: > This patch factor out madvise's core functionality so that upcoming > patch can reuse it without duplication. > > It shouldn't change any behavior. > > Signed-off-by: Minchan Kim <minchan@kernel.org> > --- > mm/madvise.c | 168 +++++++++++++++++++++++++++------------------------ > 1 file changed, 89 insertions(+), 79 deletions(-) > > diff --git a/mm/madvise.c b/mm/madvise.c > index 9a6698b56845..119e82e1f065 100644 > --- a/mm/madvise.c > +++ b/mm/madvise.c > @@ -742,7 +742,8 @@ static long madvise_dontneed_single_vma(struct vm_area_struct *vma, > return 0; > } > > -static long madvise_dontneed_free(struct vm_area_struct *vma, > +static long madvise_dontneed_free(struct task_struct *tsk, > + struct vm_area_struct *vma, > struct vm_area_struct **prev, > unsigned long start, unsigned long end, > int behavior) > @@ -754,8 +755,8 @@ static long madvise_dontneed_free(struct vm_area_struct *vma, > if (!userfaultfd_remove(vma, start, end)) { > *prev = NULL; /* mmap_sem has been dropped, prev is stale */ > > - down_read(¤t->mm->mmap_sem); > - vma = find_vma(current->mm, start); > + down_read(&tsk->mm->mmap_sem); > + vma = find_vma(tsk->mm, start); > if (!vma) > return -ENOMEM; > if (start < vma->vm_start) { > @@ -802,7 +803,8 @@ static long madvise_dontneed_free(struct vm_area_struct *vma, > * Application wants to free up the pages and associated backing store. > * This is effectively punching a hole into the middle of a file. > */ > -static long madvise_remove(struct vm_area_struct *vma, > +static long madvise_remove(struct task_struct *tsk, > + struct vm_area_struct *vma, > struct vm_area_struct **prev, > unsigned long start, unsigned long end) > { > @@ -836,13 +838,13 @@ static long madvise_remove(struct vm_area_struct *vma, > get_file(f); > if (userfaultfd_remove(vma, start, end)) { > /* mmap_sem was not released by userfaultfd_remove() */ > - up_read(¤t->mm->mmap_sem); > + up_read(&tsk->mm->mmap_sem); > } > error = vfs_fallocate(f, > FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, > offset, end - start); > fput(f); > - down_read(¤t->mm->mmap_sem); > + down_read(&tsk->mm->mmap_sem); > return error; > } > > @@ -916,12 +918,13 @@ static int madvise_inject_error(int behavior, > #endif What about madvise_inject_error() and get_user_pages_fast() in it please? > > static long > -madvise_vma(struct vm_area_struct *vma, struct vm_area_struct **prev, > - unsigned long start, unsigned long end, int behavior) > +madvise_vma(struct task_struct *tsk, struct vm_area_struct *vma, > + struct vm_area_struct **prev, unsigned long start, > + unsigned long end, int behavior) > { > switch (behavior) { > case MADV_REMOVE: > - return madvise_remove(vma, prev, start, end); > + return madvise_remove(tsk, vma, prev, start, end); > case MADV_WILLNEED: > return madvise_willneed(vma, prev, start, end); > case MADV_COOL: > @@ -930,7 +933,8 @@ madvise_vma(struct vm_area_struct *vma, struct vm_area_struct **prev, > return madvise_cold(vma, start, end); > case MADV_FREE: > case MADV_DONTNEED: > - return madvise_dontneed_free(vma, prev, start, end, behavior); > + return madvise_dontneed_free(tsk, vma, prev, start, > + end, behavior); > default: > return madvise_behavior(vma, prev, start, end, behavior); > } > @@ -974,68 +978,8 @@ madvise_behavior_valid(int behavior) > } > } > > -/* > - * The madvise(2) system call. > - * > - * Applications can use madvise() to advise the kernel how it should > - * handle paging I/O in this VM area. The idea is to help the kernel > - * use appropriate read-ahead and caching techniques. The information > - * provided is advisory only, and can be safely disregarded by the > - * kernel without affecting the correct operation of the application. > - * > - * behavior values: > - * MADV_NORMAL - the default behavior is to read clusters. This > - * results in some read-ahead and read-behind. > - * MADV_RANDOM - the system should read the minimum amount of data > - * on any access, since it is unlikely that the appli- > - * cation will need more than what it asks for. > - * MADV_SEQUENTIAL - pages in the given range will probably be accessed > - * once, so they can be aggressively read ahead, and > - * can be freed soon after they are accessed. > - * MADV_WILLNEED - the application is notifying the system to read > - * some pages ahead. > - * MADV_DONTNEED - the application is finished with the given range, > - * so the kernel can free resources associated with it. > - * MADV_FREE - the application marks pages in the given range as lazy free, > - * where actual purges are postponed until memory pressure happens. > - * MADV_REMOVE - the application wants to free up the given range of > - * pages and associated backing store. > - * MADV_DONTFORK - omit this area from child's address space when forking: > - * typically, to avoid COWing pages pinned by get_user_pages(). > - * MADV_DOFORK - cancel MADV_DONTFORK: no longer omit this area when forking. > - * MADV_WIPEONFORK - present the child process with zero-filled memory in this > - * range after a fork. > - * MADV_KEEPONFORK - undo the effect of MADV_WIPEONFORK > - * MADV_HWPOISON - trigger memory error handler as if the given memory range > - * were corrupted by unrecoverable hardware memory failure. > - * MADV_SOFT_OFFLINE - try to soft-offline the given range of memory. > - * MADV_MERGEABLE - the application recommends that KSM try to merge pages in > - * this area with pages of identical content from other such areas. > - * MADV_UNMERGEABLE- cancel MADV_MERGEABLE: no longer merge pages with others. > - * MADV_HUGEPAGE - the application wants to back the given range by transparent > - * huge pages in the future. Existing pages might be coalesced and > - * new pages might be allocated as THP. > - * MADV_NOHUGEPAGE - mark the given range as not worth being backed by > - * transparent huge pages so the existing pages will not be > - * coalesced into THP and new pages will not be allocated as THP. > - * MADV_DONTDUMP - the application wants to prevent pages in the given range > - * from being included in its core dump. > - * MADV_DODUMP - cancel MADV_DONTDUMP: no longer exclude from core dump. > - * > - * return values: > - * zero - success > - * -EINVAL - start + len < 0, start is not page-aligned, > - * "behavior" is not a valid value, or application > - * is attempting to release locked or shared pages, > - * or the specified address range includes file, Huge TLB, > - * MAP_SHARED or VMPFNMAP range. > - * -ENOMEM - addresses in the specified range are not currently > - * mapped, or are outside the AS of the process. > - * -EIO - an I/O error occurred while paging in data. > - * -EBADF - map exists, but area maps something that isn't a file. > - * -EAGAIN - a kernel resource was temporarily unavailable. > - */ > -SYSCALL_DEFINE3(madvise, unsigned long, start, size_t, len_in, int, behavior) > +static int madvise_core(struct task_struct *tsk, unsigned long start, > + size_t len_in, int behavior) > { > unsigned long end, tmp; > struct vm_area_struct *vma, *prev; > @@ -1071,10 +1015,10 @@ SYSCALL_DEFINE3(madvise, unsigned long, start, size_t, len_in, int, behavior) > > write = madvise_need_mmap_write(behavior); > if (write) { > - if (down_write_killable(¤t->mm->mmap_sem)) > + if (down_write_killable(&tsk->mm->mmap_sem)) > return -EINTR; > } else { > - down_read(¤t->mm->mmap_sem); > + down_read(&tsk->mm->mmap_sem); > } > > /* > @@ -1082,7 +1026,7 @@ SYSCALL_DEFINE3(madvise, unsigned long, start, size_t, len_in, int, behavior) > * ranges, just ignore them, but return -ENOMEM at the end. > * - different from the way of handling in mlock etc. > */ > - vma = find_vma_prev(current->mm, start, &prev); > + vma = find_vma_prev(tsk->mm, start, &prev); > if (vma && start > vma->vm_start) > prev = vma; > > @@ -1107,7 +1051,7 @@ SYSCALL_DEFINE3(madvise, unsigned long, start, size_t, len_in, int, behavior) > tmp = end; > > /* Here vma->vm_start <= start < tmp <= (end|vma->vm_end). */ > - error = madvise_vma(vma, &prev, start, tmp, behavior); > + error = madvise_vma(tsk, vma, &prev, start, tmp, behavior); > if (error) > goto out; > start = tmp; > @@ -1119,14 +1063,80 @@ SYSCALL_DEFINE3(madvise, unsigned long, start, size_t, len_in, int, behavior) > if (prev) > vma = prev->vm_next; > else /* madvise_remove dropped mmap_sem */ > - vma = find_vma(current->mm, start); > + vma = find_vma(tsk->mm, start); > } > out: > blk_finish_plug(&plug); > if (write) > - up_write(¤t->mm->mmap_sem); > + up_write(&tsk->mm->mmap_sem); > else > - up_read(¤t->mm->mmap_sem); > + up_read(&tsk->mm->mmap_sem); > > return error; > } > + > +/* > + * The madvise(2) system call. > + * > + * Applications can use madvise() to advise the kernel how it should > + * handle paging I/O in this VM area. The idea is to help the kernel > + * use appropriate read-ahead and caching techniques. The information > + * provided is advisory only, and can be safely disregarded by the > + * kernel without affecting the correct operation of the application. > + * > + * behavior values: > + * MADV_NORMAL - the default behavior is to read clusters. This > + * results in some read-ahead and read-behind. > + * MADV_RANDOM - the system should read the minimum amount of data > + * on any access, since it is unlikely that the appli- > + * cation will need more than what it asks for. > + * MADV_SEQUENTIAL - pages in the given range will probably be accessed > + * once, so they can be aggressively read ahead, and > + * can be freed soon after they are accessed. > + * MADV_WILLNEED - the application is notifying the system to read > + * some pages ahead. > + * MADV_DONTNEED - the application is finished with the given range, > + * so the kernel can free resources associated with it. > + * MADV_FREE - the application marks pages in the given range as lazy free, > + * where actual purges are postponed until memory pressure happens. > + * MADV_REMOVE - the application wants to free up the given range of > + * pages and associated backing store. > + * MADV_DONTFORK - omit this area from child's address space when forking: > + * typically, to avoid COWing pages pinned by get_user_pages(). > + * MADV_DOFORK - cancel MADV_DONTFORK: no longer omit this area when forking. > + * MADV_WIPEONFORK - present the child process with zero-filled memory in this > + * range after a fork. > + * MADV_KEEPONFORK - undo the effect of MADV_WIPEONFORK > + * MADV_HWPOISON - trigger memory error handler as if the given memory range > + * were corrupted by unrecoverable hardware memory failure. > + * MADV_SOFT_OFFLINE - try to soft-offline the given range of memory. > + * MADV_MERGEABLE - the application recommends that KSM try to merge pages in > + * this area with pages of identical content from other such areas. > + * MADV_UNMERGEABLE- cancel MADV_MERGEABLE: no longer merge pages with others. > + * MADV_HUGEPAGE - the application wants to back the given range by transparent > + * huge pages in the future. Existing pages might be coalesced and > + * new pages might be allocated as THP. > + * MADV_NOHUGEPAGE - mark the given range as not worth being backed by > + * transparent huge pages so the existing pages will not be > + * coalesced into THP and new pages will not be allocated as THP. > + * MADV_DONTDUMP - the application wants to prevent pages in the given range > + * from being included in its core dump. > + * MADV_DODUMP - cancel MADV_DONTDUMP: no longer exclude from core dump. > + * > + * return values: > + * zero - success > + * -EINVAL - start + len < 0, start is not page-aligned, > + * "behavior" is not a valid value, or application > + * is attempting to release locked or shared pages, > + * or the specified address range includes file, Huge TLB, > + * MAP_SHARED or VMPFNMAP range. > + * -ENOMEM - addresses in the specified range are not currently > + * mapped, or are outside the AS of the process. > + * -EIO - an I/O error occurred while paging in data. > + * -EBADF - map exists, but area maps something that isn't a file. > + * -EAGAIN - a kernel resource was temporarily unavailable. > + */ > +SYSCALL_DEFINE3(madvise, unsigned long, start, size_t, len_in, int, behavior) > +{ > + return madvise_core(current, start, len_in, behavior); > +} > -- > 2.21.0.1020.gf2820cf01a-goog > -- Best regards, Oleksandr Natalenko (post-factum) Senior Software Maintenance Engineer
next prev parent reply other threads:[~2019-05-20 14:26 UTC|newest] Thread overview: 138+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-20 3:52 [RFC 0/7] introduce memory hinting API for external process Minchan Kim 2019-05-20 3:52 ` [RFC 1/7] mm: introduce MADV_COOL Minchan Kim 2019-05-20 8:16 ` Michal Hocko 2019-05-20 8:19 ` Michal Hocko 2019-05-20 15:08 ` Suren Baghdasaryan 2019-05-20 22:55 ` Minchan Kim 2019-05-20 22:54 ` Minchan Kim 2019-05-21 6:04 ` Michal Hocko 2019-05-21 9:11 ` Minchan Kim 2019-05-21 10:05 ` Michal Hocko 2019-05-28 8:53 ` Hillf Danton 2019-05-28 10:58 ` Minchan Kim 2019-05-20 3:52 ` [RFC 2/7] mm: change PAGEREF_RECLAIM_CLEAN with PAGE_REFRECLAIM Minchan Kim 2019-05-20 16:50 ` Johannes Weiner 2019-05-20 22:57 ` Minchan Kim 2019-05-20 3:52 ` [RFC 3/7] mm: introduce MADV_COLD Minchan Kim 2019-05-20 8:27 ` Michal Hocko 2019-05-20 23:00 ` Minchan Kim 2019-05-21 6:08 ` Michal Hocko 2019-05-21 9:13 ` Minchan Kim 2019-05-28 14:54 ` Hillf Danton 2019-05-30 0:45 ` Minchan Kim 2019-05-20 3:52 ` [RFC 4/7] mm: factor out madvise's core functionality Minchan Kim 2019-05-20 14:26 ` Oleksandr Natalenko [this message] 2019-05-21 1:26 ` Minchan Kim 2019-05-21 6:36 ` Oleksandr Natalenko 2019-05-21 6:50 ` Michal Hocko 2019-05-21 7:06 ` Oleksandr Natalenko 2019-05-21 10:52 ` Minchan Kim 2019-05-21 11:00 ` Michal Hocko 2019-05-21 11:24 ` Minchan Kim 2019-05-21 11:32 ` Michal Hocko 2019-05-21 10:49 ` Minchan Kim 2019-05-21 10:55 ` Michal Hocko 2019-05-20 3:52 ` [RFC 5/7] mm: introduce external memory hinting API Minchan Kim 2019-05-20 9:18 ` Michal Hocko 2019-05-21 2:41 ` Minchan Kim 2019-05-21 6:17 ` Michal Hocko 2019-05-21 10:32 ` Minchan Kim 2019-05-21 9:01 ` Christian Brauner 2019-05-21 11:35 ` Minchan Kim 2019-05-21 11:51 ` Christian Brauner 2019-05-21 15:31 ` Oleg Nesterov 2019-05-27 7:43 ` Minchan Kim 2019-05-27 15:12 ` Oleg Nesterov 2019-05-27 23:33 ` Minchan Kim 2019-05-28 7:23 ` Michal Hocko 2019-05-29 3:41 ` Hillf Danton 2019-05-30 0:38 ` Minchan Kim 2019-05-20 3:52 ` [RFC 6/7] mm: extend process_madvise syscall to support vector arrary Minchan Kim 2019-05-20 9:22 ` Michal Hocko 2019-05-21 2:48 ` Minchan Kim 2019-05-21 6:24 ` Michal Hocko 2019-05-21 10:26 ` Minchan Kim 2019-05-21 10:37 ` Michal Hocko 2019-05-27 7:49 ` Minchan Kim 2019-05-29 10:08 ` Daniel Colascione 2019-05-29 10:33 ` Michal Hocko 2019-05-30 2:17 ` Minchan Kim 2019-05-30 6:57 ` Michal Hocko 2019-05-30 8:02 ` Minchan Kim 2019-05-30 16:19 ` Daniel Colascione 2019-05-30 18:47 ` Michal Hocko 2019-05-29 4:14 ` Hillf Danton 2019-05-30 0:35 ` Minchan Kim 2019-05-20 3:52 ` [RFC 7/7] mm: madvise support MADV_ANONYMOUS_FILTER and MADV_FILE_FILTER Minchan Kim 2019-05-20 9:28 ` Michal Hocko 2019-05-21 2:55 ` Minchan Kim 2019-05-21 6:26 ` Michal Hocko 2019-05-27 7:58 ` Minchan Kim 2019-05-27 12:44 ` Michal Hocko 2019-05-28 3:26 ` Minchan Kim 2019-05-28 6:29 ` Michal Hocko 2019-05-28 8:13 ` Minchan Kim 2019-05-28 8:31 ` Daniel Colascione 2019-05-28 8:49 ` Minchan Kim 2019-05-28 9:08 ` Michal Hocko 2019-05-28 9:39 ` Daniel Colascione 2019-05-28 10:33 ` Michal Hocko 2019-05-28 11:21 ` Daniel Colascione 2019-05-28 11:49 ` Michal Hocko 2019-05-28 12:11 ` Daniel Colascione 2019-05-28 12:32 ` Michal Hocko 2019-05-28 10:32 ` Minchan Kim 2019-05-28 10:41 ` Michal Hocko 2019-05-28 11:12 ` Minchan Kim 2019-05-28 11:28 ` Michal Hocko 2019-05-28 11:42 ` Daniel Colascione 2019-05-28 11:56 ` Michal Hocko 2019-05-28 12:18 ` Daniel Colascione 2019-05-28 12:38 ` Michal Hocko 2019-05-28 12:10 ` Minchan Kim 2019-05-28 11:44 ` Minchan Kim 2019-05-28 11:51 ` Daniel Colascione 2019-05-28 12:06 ` Michal Hocko 2019-05-28 12:22 ` Minchan Kim 2019-05-28 11:28 ` Daniel Colascione 2019-05-21 15:33 ` Johannes Weiner 2019-05-22 1:50 ` Minchan Kim 2019-05-29 4:36 ` Hillf Danton 2019-05-30 1:00 ` Minchan Kim 2019-05-20 6:37 ` [RFC 0/7] introduce memory hinting API for external process Anshuman Khandual 2019-05-20 16:59 ` Tim Murray 2019-05-21 2:55 ` Anshuman Khandual 2019-05-21 5:14 ` Minchan Kim 2019-05-21 10:34 ` Michal Hocko 2019-05-28 10:50 ` Anshuman Khandual 2019-05-21 12:56 ` Shakeel Butt 2019-05-22 4:15 ` Brian Geffon 2019-05-22 4:23 ` Brian Geffon 2019-05-20 9:28 ` Michal Hocko 2019-05-20 14:42 ` Oleksandr Natalenko 2019-05-21 2:56 ` Minchan Kim 2019-05-20 16:46 ` Johannes Weiner 2019-05-21 4:39 ` Minchan Kim 2019-05-21 6:32 ` Michal Hocko 2019-05-21 1:44 ` Matthew Wilcox 2019-05-21 5:01 ` Minchan Kim 2019-05-21 6:34 ` Michal Hocko 2019-05-21 8:42 ` Christian Brauner 2019-05-21 11:05 ` Minchan Kim 2019-05-21 11:30 ` Christian Brauner 2019-05-21 11:39 ` Christian Brauner 2019-05-22 5:11 ` Daniel Colascione 2019-05-22 8:22 ` Christian Brauner 2019-05-22 13:16 ` Daniel Colascione 2019-05-22 14:52 ` Christian Brauner 2019-05-22 15:17 ` Daniel Colascione 2019-05-22 15:48 ` Christian Brauner 2019-05-22 15:57 ` Daniel Colascione 2019-05-22 16:01 ` Christian Brauner 2019-05-22 16:01 ` Daniel Colascione 2019-05-23 13:07 ` Minchan Kim 2019-05-27 8:06 ` Minchan Kim 2019-05-21 11:41 ` Minchan Kim 2019-05-21 12:04 ` Christian Brauner 2019-05-21 12:15 ` Oleksandr Natalenko 2019-05-21 12:53 ` Shakeel Butt
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=20190520142633.x5d27gk454qruc4o@butterfly.localdomain \ --to=oleksandr@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=bgeffon@google.com \ --cc=dancol@google.com \ --cc=hannes@cmpxchg.org \ --cc=joel@joelfernandes.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@suse.com \ --cc=minchan@kernel.org \ --cc=shakeelb@google.com \ --cc=sonnyrao@google.com \ --cc=surenb@google.com \ --cc=timmurray@google.com \ --subject='Re: [RFC 4/7] mm: factor out madvise'\''s core functionality' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).