linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Avi Kivity <avi@redhat.com>
Cc: Rik van Riel <riel@redhat.com>,
	linux-kernel@vger.kernel.org, aarcange@redhat.com,
	akpm@linux-foundation.org,
	Kent Overstreet <kent.overstreet@gmail.com>,
	Ingo Molnar <mingo@elte.hu>, tglx <tglx@linutronix.de>
Subject: Re: [COUNTERPATCH] mm: avoid overflowing preempt_count() in  mmu_take_all_locks()
Date: Thu, 01 Apr 2010 12:31:46 +0200	[thread overview]
Message-ID: <1270117906.1653.139.camel@laptop> (raw)
In-Reply-To: <1270114817-28896-1-git-send-email-avi@redhat.com>

I'm sure you dropped Ingo and Thomas by accident.

On Thu, 2010-04-01 at 12:40 +0300, Avi Kivity wrote:
> mmu_take_all_locks() takes a spinlock for each vma, which means we increase
> the preempt count by the number of vmas in an address space.  Since the user
> controls the number of vmas, they can cause preempt_count to overflow.
> 
> Fix by making mmu_take_all_locks() only disable preemption once by making
> the spinlocks preempt-neutral.

Right, so while this will get rid of the warning it doesn't make the
code any nicer, its still a massive !preempt latency spot.

> Signed-off-by: Avi Kivity <avi@redhat.com>
> ---
>  mm/mmap.c |   37 +++++++++++++++++++++++++++++++++++++
>  1 files changed, 37 insertions(+), 0 deletions(-)
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 75557c6..7305510 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2442,6 +2442,12 @@ static void vm_lock_anon_vma(struct mm_struct *mm, struct anon_vma *anon_vma)
>  		 */
>  		spin_lock_nest_lock(&anon_vma->lock, &mm->mmap_sem);
>  		/*
> +		 * To avoid O(nr_vmas) preempt_disable()s, we keep each
> +		 * vma preemp_count neutral and instead disable preempt
> +		 * once per mmu_take_all_lock().
> +		 */
> +		preempt_enable();
> +		/*
>  		 * We can safely modify head.next after taking the
>  		 * anon_vma->lock. If some other vma in this mm shares
>  		 * the same anon_vma we won't take it again.
> @@ -2471,6 +2477,12 @@ static void vm_lock_mapping(struct mm_struct *mm, struct address_space *mapping)
>  		if (test_and_set_bit(AS_MM_ALL_LOCKS, &mapping->flags))
>  			BUG();
>  		spin_lock_nest_lock(&mapping->i_mmap_lock, &mm->mmap_sem);
> +		/*
> +		 * To avoid O(nr_vmas) preempt_disable()s, we keep each
> +		 * vma preemp_count neutral and instead disable preempt
> +		 * once per mmu_take_all_lock().
> +		 */
> +		preempt_enable();
>  	}
>  }
>  
> @@ -2516,6 +2528,13 @@ int mm_take_all_locks(struct mm_struct *mm)
>  
>  	mutex_lock(&mm_all_locks_mutex);
>  
> +	/*
> +	 * To avoid O(nr_vmas) preempt_disable()s, we keep each
> +	 * vma preemp_count neutral and instead disable preempt
> +	 * once per mmu_take_all_lock().
> +	 */
> +	preempt_disable();
> +
>  	for (vma = mm->mmap; vma; vma = vma->vm_next) {
>  		if (signal_pending(current))
>  			goto out_unlock;
> @@ -2558,6 +2577,12 @@ static void vm_unlock_anon_vma(struct anon_vma *anon_vma)
>  		if (!__test_and_clear_bit(0, (unsigned long *)
>  					  &anon_vma->head.next))
>  			BUG();
> +		/*
> +		 * To avoid O(nr_vmas) preempt_disable()s, we keep each
> +		 * vma preemp_count neutral and instead disable preempt
> +		 * once per mmu_take_all_lock().
> +		 */
> +		preempt_disable();
>  		spin_unlock(&anon_vma->lock);
>  	}
>  }
> @@ -2569,6 +2594,12 @@ static void vm_unlock_mapping(struct address_space *mapping)
>  		 * AS_MM_ALL_LOCKS can't change to 0 from under us
>  		 * because we hold the mm_all_locks_mutex.
>  		 */
> +		/*
> +		 * To avoid O(nr_vmas) preempt_disable()s, we keep each
> +		 * vma preemp_count neutral and instead disable preempt
> +		 * once per mmu_take_all_lock().
> +		 */
> +		preempt_disable();
>  		spin_unlock(&mapping->i_mmap_lock);
>  		if (!test_and_clear_bit(AS_MM_ALL_LOCKS,
>  					&mapping->flags))
> @@ -2596,6 +2627,12 @@ void mm_drop_all_locks(struct mm_struct *mm)
>  			vm_unlock_mapping(vma->vm_file->f_mapping);
>  	}
>  
> +	/*
> +	 * To avoid O(nr_vmas) preempt_disable()s, we keep each
> +	 * vma preemp_count neutral and instead disable preempt
> +	 * once per mmu_take_all_lock().
> +	 */
> +	preempt_enable();
>  	mutex_unlock(&mm_all_locks_mutex);
>  }
>  




  reply	other threads:[~2010-04-01 10:31 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-30 17:36 [PATCH] increase PREEMPT_BITS to 12 to avoid overflow when starting KVM Rik van Riel
2010-03-30 17:56 ` Peter Zijlstra
2010-03-30 18:05   ` Rik van Riel
2010-03-30 18:34     ` Peter Zijlstra
2010-04-01  9:40 ` [COUNTERPATCH] mm: avoid overflowing preempt_count() in mmu_take_all_locks() Avi Kivity
2010-04-01 10:31   ` Peter Zijlstra [this message]
2010-04-01 11:04     ` Thomas Gleixner
2010-04-01 11:13       ` Avi Kivity
2010-04-01 11:16         ` Peter Zijlstra
2010-04-01 11:19           ` Avi Kivity
2010-04-01 15:36           ` Andrea Arcangeli
2010-04-01 15:39             ` Avi Kivity
2010-04-01 15:54               ` Andrea Arcangeli
2010-04-01 16:02                 ` Avi Kivity
2010-04-01 16:12                   ` Andrea Arcangeli
2010-04-01 11:17         ` Avi Kivity
2010-04-01 11:27           ` Peter Zijlstra
2010-04-01 11:43             ` Peter Zijlstra
2010-04-01 11:47               ` Avi Kivity
2010-04-01 15:42               ` Andrea Arcangeli
2010-04-01 15:50                 ` Peter Zijlstra
2010-04-01 15:56                   ` Peter Zijlstra
2010-04-01 16:07                     ` Andrea Arcangeli
2010-04-01 16:32                       ` Peter Zijlstra
2010-04-01 16:00                   ` Andrea Arcangeli
2010-04-01 15:51                 ` Avi Kivity
2010-04-01 15:56                   ` Peter Zijlstra
2010-04-01 16:06                     ` Avi Kivity
2010-04-01 16:15                       ` Paul E. McKenney
2010-04-01 16:36                         ` Peter Zijlstra
2010-04-01 17:02                           ` Paul E. McKenney
2010-04-01 16:08                     ` Andrea Arcangeli
2010-04-01 16:14                     ` Paul E. McKenney
2010-04-01 16:02                   ` Andrea Arcangeli
2010-04-01 16:12                 ` Peter Zijlstra
2010-04-01 16:18                   ` Andrea Arcangeli
2010-04-01 16:45                     ` Peter Zijlstra
2010-04-01 16:49                       ` Peter Zijlstra
2010-04-01 17:04                         ` Andrea Arcangeli
2010-04-01 14:16       ` Rik van Riel
2010-04-01 15:32       ` Andrea Arcangeli
2010-04-01 15:37         ` Avi Kivity
2010-04-01 11:09     ` Avi Kivity

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=1270117906.1653.139.camel@laptop \
    --to=peterz@infradead.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=avi@redhat.com \
    --cc=kent.overstreet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=riel@redhat.com \
    --cc=tglx@linutronix.de \
    /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).