public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Roland McGrath <roland@redhat.com>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Steven Rostedt <srostedt@redhat.com>,
	Hugh Dickins <hugh@veritas.com>
Subject: Re: [PATCH 5/5] mm: remove unlikelys for unlock in rmap.c
Date: Fri, 24 Apr 2009 08:15:43 -0400	[thread overview]
Message-ID: <1240575343.4315.15.camel@lts-notebook> (raw)
In-Reply-To: <20090424200713.108B.A69D9226@jp.fujitsu.com>

On Fri, 2009-04-24 at 20:12 +0900, KOSAKI Motohiro wrote:
> (cc to lee)
> 
> > From: Steven Rostedt <rostedt@goodmis.org>
> > 
> > Impact: clean up
> > 
> > The annotated branch profiler shows that the rmap calls are likely
> > called with unlock set.
> > 
> >  correct incorrect  %        Function                  File              Line
> >  ------- ---------  -        --------                  ----              ----
> >        0    46100 100 try_to_unmap_anon              rmap.c               1013
> >        0    46100 100 try_to_unmap_anon              rmap.c               1005
> >        0     5763 100 try_to_unmap_file              rmap.c               1074
> >        0     5763 100 try_to_unmap_file              rmap.c               1069
> > 
> > Signed-off-by: Steven Rostedt <srostedt@redhat.com>
> 
> unlock==1 mean munlock() is called.
> unlock==0 mean memory shortage and reclaim happend.
> 
> So, we did guess end-user don't use munlock() so frequently.
> but reclaim is frequently happend.
> 
> Oh well, but you have rich machine. hmm...
> ok, I can agree user can use munlock() frequently.
> 
> 
> 	Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> 

In current mainline, try_to_munlock() is called only from
munlock_vma_page() and then only when page is actually mlocked.  So, you
should only see the profile above during a test that is munlock()ing a
lot of pages.  However, after try_to_munlock() was introduced, we'd
added a call to it in vmscan.c to test for mlocked anon pages to avoid
allocating swap to mlocked pages.  At the time, we couldn't reliably
free swap there.  Hugh fixed this and removed the call from vmscan.  If
Steve was testing a kernel before the call was removed, he would have
seen the calls when reclaiming any anon pages.

Steve:  what test were you using and on what version?

Regards,
Lee

> 
> 
> 
> > ---
> >  mm/rmap.c |    8 ++++----
> >  1 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/mm/rmap.c b/mm/rmap.c
> > index 1652166..ad62fe0 100644
> > --- a/mm/rmap.c
> > +++ b/mm/rmap.c
> > @@ -1002,7 +1002,7 @@ static int try_to_unmap_anon(struct page *page, int unlock, int migration)
> >  	unsigned int mlocked = 0;
> >  	int ret = SWAP_AGAIN;
> >  
> > -	if (MLOCK_PAGES && unlikely(unlock))
> > +	if (MLOCK_PAGES && unlock)
> >  		ret = SWAP_SUCCESS;	/* default for try_to_munlock() */
> >  
> >  	anon_vma = page_lock_anon_vma(page);
> > @@ -1010,7 +1010,7 @@ static int try_to_unmap_anon(struct page *page, int unlock, int migration)
> >  		return ret;
> >  
> >  	list_for_each_entry(vma, &anon_vma->head, anon_vma_node) {
> > -		if (MLOCK_PAGES && unlikely(unlock)) {
> > +		if (MLOCK_PAGES && unlock) {
> >  			if (!((vma->vm_flags & VM_LOCKED) &&
> >  			      page_mapped_in_vma(page, vma)))
> >  				continue;  /* must visit all unlocked vmas */
> > @@ -1066,12 +1066,12 @@ static int try_to_unmap_file(struct page *page, int unlock, int migration)
> >  	unsigned int mapcount;
> >  	unsigned int mlocked = 0;
> >  
> > -	if (MLOCK_PAGES && unlikely(unlock))
> > +	if (MLOCK_PAGES && unlock)
> >  		ret = SWAP_SUCCESS;	/* default for try_to_munlock() */
> >  
> >  	spin_lock(&mapping->i_mmap_lock);
> >  	vma_prio_tree_foreach(vma, &iter, &mapping->i_mmap, pgoff, pgoff) {
> > -		if (MLOCK_PAGES && unlikely(unlock)) {
> > +		if (MLOCK_PAGES && unlock) {
> >  			if (!((vma->vm_flags & VM_LOCKED) &&
> >  						page_mapped_in_vma(page, vma)))
> >  				continue;	/* must visit all vmas */
> > -- 
> > 1.6.2
> > 
> > -- 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> 


  reply	other threads:[~2009-04-24 12:15 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-25  5:19 [PATCH 0/5] [PATCH][GIT PULL] remove unnecessary (un)likelys Steven Rostedt
2009-03-25  5:19 ` [PATCH 1/5] ptrace: remove incorrect unlikelys Steven Rostedt
2009-03-25  7:21   ` Ingo Molnar
2009-03-25 13:31     ` Christian Borntraeger
2009-03-25 13:42     ` Steven Rostedt
2009-03-25  9:28   ` Roland McGrath
2009-03-25  5:19 ` [PATCH 2/5] mm: remove unlikly NULL from kfree Steven Rostedt
2009-03-25  7:34   ` Pekka Enberg
2009-03-25  7:50     ` Thomas Gleixner
2009-03-25  8:01       ` Pekka Enberg
2009-03-25 21:20       ` Andrew Morton
2009-03-25  8:02     ` Hua Zhong
2009-03-25  8:06       ` Pekka Enberg
2009-03-25 13:51         ` Pekka Enberg
2009-03-25 14:47           ` Steven Rostedt
2009-03-25 14:59             ` Pekka Enberg
2009-03-25 15:04               ` Steven Rostedt
2009-03-25 15:08                 ` Steven Rostedt
2009-03-25 16:14                   ` Matt Mackall
2009-03-25 16:34                     ` Steven Rostedt
2009-03-25 20:26                       ` Jeremy Fitzhardinge
2009-03-25 21:09                         ` Matt Mackall
2009-03-25 21:01                       ` Matt Mackall
2009-03-25 21:24                         ` Steven Rostedt
2009-03-25 15:27             ` Steven Rostedt
2009-03-26 16:10           ` Al Viro
2009-03-26 16:15             ` Andrew Morton
2009-03-25  5:19 ` [PATCH 3/5] sched: remove unlikely in pre_schedule_rt Steven Rostedt
2009-03-25  5:24   ` Steven Rostedt
2009-03-25  5:19 ` [PATCH 4/5] sched: remove unlikelys from sched_move_task Steven Rostedt
2009-03-25  5:19 ` [PATCH 5/5] mm: remove unlikelys for unlock in rmap.c Steven Rostedt
2009-04-24 11:12   ` KOSAKI Motohiro
2009-04-24 12:15     ` Lee Schermerhorn [this message]
2009-03-25  7:19 ` [PATCH 0/5] [PATCH][GIT PULL] remove unnecessary (un)likelys Ingo Molnar
2009-03-25  7:25 ` Ingo Molnar
2009-03-25 13:43   ` Steven Rostedt
2009-04-27 16:30 ` Daniel Walker

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=1240575343.4315.15.camel@lts-notebook \
    --to=lee.schermerhorn@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=hugh@veritas.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=peterz@infradead.org \
    --cc=roland@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=srostedt@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