linux-kernel - Re: [PATCH 5/5] mm: remove unlikelys for unlock in rmap.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090424200713.108B.A69D9226@jp.fujitsu.com>
Date:	Fri, 24 Apr 2009 20:12:01 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	kosaki.motohiro@...fujitsu.com, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Roland McGrath <roland@...hat.com>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Steven Rostedt <srostedt@...hat.com>,
	Lee Schermerhorn <Lee.Schermerhorn@...com>
Subject: Re: [PATCH 5/5] mm: remove unlikelys for unlock in rmap.c

(cc to lee)

> From: Steven Rostedt <rostedt@...dmis.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@...hat.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@...fujitsu.com>




> ---
>  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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/