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: <4414cca4-1a09-ebda-c92b-fa98df1c8e31@suse.cz>
Date:   Fri, 6 Jan 2017 09:00:23 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Steven Rostedt <rostedt@...dmis.org>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     Mel Gorman <mgorman@...hsingularity.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Dirk Hohndel <dirkhh@...are.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>
Subject: Re: mm, page_alloc: Swap likely to unlikely as code logic is
 different for next_zones_zonelist()

On 01/06/2017 02:01 AM, Steven Rostedt wrote:
> Commit 682a3385e773 "mm, page_alloc: inline the fast path of the
> zonelist iterator" changed how next_zones_zonelist() is called, by
> adding a static inline function to do the fast path. This function adds:
> 
>        if (likely(!nodes && zonelist_zone_idx(z) <= highest_zoneidx))

Your profiling stats posted online suggested even this one was wrong:

          function.file.line         correct 	incorrect 	percent
next_zones_zonelist.mmzone.h.965    216840653	25415261543	%0.85

Was it bogus then, or is there other explanation? I have speculated that
this might be due to multiple cpusets configured in the system.

>                return z;
>        return __next_zones_zonelist(z, highest_zoneidx, nodes);
> 
> Where __next_zones_zonelist() is only called when nodes is not NULL or
> zonelist_zone_idx(z) is less than highest_zoneidx.
> 
> The original next_zone_zonelist() was converted to
> __next_zones_zonelist() but it still maintained:
> 
> 	if (likely(nodes == NULL))
> 
> Which is now actually a very unlikely, as it is only called with nodes
> equal to NULL when zonelist_zone_idx(z) is greater than highest_zoneidx.
> 
> Before this commit, this if had this statistic:
> 
>  correct incorrect  %        Function                  File              Line
>  ------- ---------  -        --------                  ----              ----
>   837895   446078  34 next_zones_zonelist            mmzone.c             63
> 
> After this commit, it has:
> 
>  correct incorrect  %        Function                  File              Line
>  ------- ---------  -        --------                  ----              ----
>       10   173840  99 __next_zones_zonelist          mmzone.c             63
> 
> Thus, the if statement is now much more unlikely than it ever was as a
> likely.
> 
> Signed-off-by: Steven Rostedt (VMware) <rostedt@...dmis.org>

Anyway this makes sense.

Acked-by: Vlastimil Babka <vbabka@...e.cz>

> ---
> diff --git a/mm/mmzone.c b/mm/mmzone.c
> index 5652be858e5e..a51c0a67ea3d 100644
> --- a/mm/mmzone.c
> +++ b/mm/mmzone.c
> @@ -60,7 +60,7 @@ struct zoneref *__next_zones_zonelist(struct zoneref *z,
>  	 * Find the next suitable zone to use for the allocation.
>  	 * Only filter based on nodemask if it's set
>  	 */
> -	if (likely(nodes == NULL))
> +	if (unlikely(nodes == NULL))
>  		while (zonelist_zone_idx(z) > highest_zoneidx)
>  			z++;
>  	else
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ