linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yang Shi <yang.shi@linux.alibaba.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: mhocko@kernel.org, ldufour@linux.vnet.ibm.com,
	kirill@shutemov.name, vbabka@suse.cz, akpm@linux-foundation.org,
	peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
	alexander.shishkin@linux.intel.com, jolsa@redhat.com,
	namhyung@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC v8 PATCH 3/5] mm: mmap: zap pages with read mmap_sem in munmap
Date: Wed, 15 Aug 2018 23:11:23 -0700	[thread overview]
Message-ID: <b286c2f8-d3a5-89f8-954b-608a26c28a22@linux.alibaba.com> (raw)
In-Reply-To: <20180816024652.GA11808@bombadil.infradead.org>



On 8/15/18 7:46 PM, Matthew Wilcox wrote:
> On Wed, Aug 15, 2018 at 02:54:13PM -0700, Yang Shi wrote:
>>
>> On 8/15/18 2:09 PM, Matthew Wilcox wrote:
>>> On Wed, Aug 15, 2018 at 12:16:06PM -0700, Matthew Wilcox wrote:
>>>> (not even compiled, and I can see a good opportunity for combining the
>>>> VM_LOCKED loop with the has_uprobes loop)
>>> I was rushing to get that sent earlier.  Here it is tidied up to
>>> actually compile.
>> Thanks for the example. Yes, I believe the code still can be compacted to
>> save some lines. However, the cover letter and the commit log of this patch
>> has elaborated the discussion in the earlier reviews about why we do it in
>> this way.
> You mean the other callers which need to hold mmap_sem write-locked for
> longer?  I hadn't really considered those; how about this?

Thanks. Yes, this is the other potential implementation. My rationale 
about a separate function for the optimized path is I would prefer 
optimize this step by step by starting with some relatively simple way, 
then add enhancement on top of it.

And, I would prefer keep the current implementation of do_munmap since 
it is called somewhere else and it might be called by the optimized path 
for some reason until we are confident enough that the optimization 
doesn't have regression.

This sounds like separate function vs an extra parameter. We do save 
some lines with extra parameter instead of a separate function.

Thanks,
Yang

>
>   mmap.c |   47 +++++++++++++++++++++++++++++------------------
>   1 file changed, 29 insertions(+), 18 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index de699523c0b7..06dc31d1da8c 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2798,11 +2798,11 @@ int split_vma(struct mm_struct *mm, struct vm_area_struct *vma,
>    * work.  This now handles partial unmappings.
>    * Jeremy Fitzhardinge <jeremy@goop.org>
>    */
> -int do_munmap(struct mm_struct *mm, unsigned long start, size_t len,
> -	      struct list_head *uf)
> +static int __do_munmap(struct mm_struct *mm, unsigned long start, size_t len,
> +	      struct list_head *uf, bool downgrade)
>   {
>   	unsigned long end;
> -	struct vm_area_struct *vma, *prev, *last;
> +	struct vm_area_struct *vma, *prev, *last, *tmp;
>   
>   	if ((offset_in_page(start)) || start > TASK_SIZE || len > TASK_SIZE-start)
>   		return -EINVAL;
> @@ -2816,7 +2816,7 @@ int do_munmap(struct mm_struct *mm, unsigned long start, size_t len,
>   	if (!vma)
>   		return 0;
>   	prev = vma->vm_prev;
> -	/* we have  start < vma->vm_end  */
> +	/* we have start < vma->vm_end  */
>   
>   	/* if it doesn't overlap, we have nothing.. */
>   	end = start + len;
> @@ -2873,18 +2873,22 @@ int do_munmap(struct mm_struct *mm, unsigned long start, size_t len,
>   
>   	/*
>   	 * unlock any mlock()ed ranges before detaching vmas
> +	 * and check to see if there's any reason we might have to hold
> +	 * the mmap_sem write-locked while unmapping regions.
>   	 */
> -	if (mm->locked_vm) {
> -		struct vm_area_struct *tmp = vma;
> -		while (tmp && tmp->vm_start < end) {
> -			if (tmp->vm_flags & VM_LOCKED) {
> -				mm->locked_vm -= vma_pages(tmp);
> -				munlock_vma_pages_all(tmp);
> -			}
> -			tmp = tmp->vm_next;
> +	for (tmp = vma; tmp && tmp->vm_start < end; tmp = tmp->vm_next) {
> +		if (tmp->vm_flags & VM_LOCKED) {
> +			mm->locked_vm -= vma_pages(tmp);
> +			munlock_vma_pages_all(tmp);
>   		}
> +		if (tmp->vm_file &&
> +				has_uprobes(tmp, tmp->vm_start, tmp->vm_end))
> +			downgrade = false;
>   	}
>   
> +	if (downgrade)
> +		downgrade_write(&mm->mmap_sem);
> +
>   	/*
>   	 * Remove the vma's, and unmap the actual pages
>   	 */
> @@ -2896,7 +2900,13 @@ int do_munmap(struct mm_struct *mm, unsigned long start, size_t len,
>   	/* Fix up all other VM information */
>   	remove_vma_list(mm, vma);
>   
> -	return 0;
> +	return downgrade ? 1 : 0;
> +}
> +
> +int do_unmap(struct mm_struct *mm, unsigned long start, size_t len,
> +		struct list_head *uf)
> +{
> +	return __do_munmap(mm, start, len, uf, false);
>   }
>   
>   int vm_munmap(unsigned long start, size_t len)
> @@ -2905,11 +2915,12 @@ int vm_munmap(unsigned long start, size_t len)
>   	struct mm_struct *mm = current->mm;
>   	LIST_HEAD(uf);
>   
> -	if (down_write_killable(&mm->mmap_sem))
> -		return -EINTR;
> -
> -	ret = do_munmap(mm, start, len, &uf);
> -	up_write(&mm->mmap_sem);
> +	down_write(&mm->mmap_sem);
> +	ret = __do_munmap(mm, start, len, &uf, true);
> +	if (ret == 1)
> +		up_read(&mm->mmap_sem);
> +	else
> +		up_write(&mm->mmap_sem);
>   	userfaultfd_unmap_complete(mm, &uf);
>   	return ret;
>   }


  reply	other threads:[~2018-08-16  6:11 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-15 18:49 [RFC v8 PATCH 0/5] mm: zap pages with read mmap_sem in munmap for large mapping Yang Shi
2018-08-15 18:49 ` [RFC v8 PATCH 1/5] mm: refactor do_munmap() to extract the common part Yang Shi
2018-08-15 18:49 ` [RFC v8 PATCH 2/5] uprobes: introduce has_uprobes helper Yang Shi
2018-08-22 10:55   ` Vlastimil Babka
2018-08-22 15:07     ` Srikar Dronamraju
2018-08-22 20:51       ` Yang Shi
2018-08-23 15:15       ` Oleg Nesterov
2018-08-23 16:07         ` Yang Shi
2018-08-15 18:49 ` [RFC v8 PATCH 3/5] mm: mmap: zap pages with read mmap_sem in munmap Yang Shi
2018-08-15 19:16   ` Matthew Wilcox
2018-08-15 21:09     ` Matthew Wilcox
2018-08-15 21:54       ` Yang Shi
2018-08-16  2:46         ` Matthew Wilcox
2018-08-16  6:11           ` Yang Shi [this message]
2018-08-22 11:11   ` Vlastimil Babka
2018-08-22 19:20     ` Yang Shi
2018-08-22 11:19   ` Vlastimil Babka
2018-08-22 20:45     ` Yang Shi
2018-08-22 21:10       ` Kirill A. Shutemov
2018-08-22 21:42         ` Dave Hansen
2018-08-22 21:56           ` Yang Shi
2018-08-22 22:03             ` Dave Hansen
2018-08-15 18:49 ` [RFC v8 PATCH 4/5] mm: unmap VM_HUGETLB mappings with optimized path Yang Shi
2018-08-15 18:49 ` [RFC v8 PATCH 5/5] mm: unmap VM_PFNMAP " Yang Shi

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=b286c2f8-d3a5-89f8-954b-608a26c28a22@linux.alibaba.com \
    --to=yang.shi@linux.alibaba.com \
    --cc=acme@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=jolsa@redhat.com \
    --cc=kirill@shutemov.name \
    --cc=ldufour@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).