linux-kernel - Re: [PATCH] mm/vmscan: try to optimize branch procedures.

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>] [day] [month] [year] [list]

Message-ID: <20171128094603.2umepkakzhh44eqa@techsingularity.net>
Date:   Tue, 28 Nov 2017 09:46:03 +0000
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     jiang.biao2@....com.cn
Cc:     mhocko@...nel.org, akpm@...ux-foundation.org, hannes@...xchg.org,
        hillf.zj@...baba-inc.com, minchan@...nel.org, ying.huang@...el.com,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        zhong.weidong@....com.cn
Subject: Re: [PATCH] mm/vmscan: try to optimize branch procedures.

On Tue, Nov 28, 2017 at 05:19:10PM +0800, jiang.biao2@....com.cn wrote:
> > On Tue 28-11-17 09:49:45, Jiang Biao wrote:> > 1. Use unlikely to try to improve branch prediction. The
> > > *total_scan < 0* branch is unlikely to reach, so use unlikely.
> > >
> > > 2. Optimize *next_deferred >= scanned* condition.
> > > *next_deferred >= scanned* condition could be optimized into
> > > *next_deferred > scanned*, because when *next_deferred == scanned*,
> > > next_deferred shoud be 0, which is covered by the else branch.
> > >
> > > 3. Merge two branch blocks into one. The *next_deferred > 0* branch
> > > could be merged into *next_deferred > scanned* to simplify the code.
> > 
> > How have you measured benefit of this patch?
> No accurate measurement for now.
> Theoretically, unlikely could improve branch prediction for unlikely branch.

In general, it only really matters for a heavily mispredicted path in a
fast path. It's not enforced very often but seeing a dedicated patch
making the change to a slow path is not very convincing.

> It's hard to measure the benefit of 2 and 3, any idea to do that enlightened 
> would be greatly appreciated. :)

Typically done using perf to check for mispredictions and showing a
reduction. It can also have icache benefits if code that is almost dead
is moved to another part of the function by the compiler reducing icache
pressure overall. Again, it only really matters in fast path.

> But it could simply code logic from coding 
> perspective???

It doesn't carry enough weight to stand on its own.

-- 
Mel Gorman
SUSE Labs