linux-kernel - Re: [PATCH v1] change likeliness accounting

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

Date:	Mon, 17 Mar 2008 13:45:13 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Roel Kluin <12o3l@...cali.nl>
Cc:	dwalker@...sta.com, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] change likeliness accounting

On Friday 14 March 2008 10:06, Roel Kluin wrote:
> In the patch below I propose some changes to the likely/unlikely
> accounting. ---
> In struct likeliness: store __builtin_return_address in 'caller', rather
> than __FILE__ and __func__, and combine 'type' and 'line' into one 'label'.
>
> The __check_likely macro performs some functionality originally in
> do_check_likely(): The first check for LP_UNSEEN bit, the increment of the
> experienced likely-count. do_check_likely() looses its parameter and return
> value. I added a __builtin_expect() to make use of the expectation.
>
> The likely diplay changes: now +/- denotes whether expectation fails in
> less than 0.01% of the tests rather than whether more unexpected than
> expected were encountered. __FILE__ is no longer displayed in output.

0.01%, so 1 time every 10 000 tests.

That seems pretty excessive. If the 9 999 tests which were taken
correctly each saved only 0.1 cycle due to the likely annotation,
then that would be implying the same likely annotation adds 1 000
cycles to the cost of the branch when taken that way.

In practice, I'd say it is probably just going to cost an extra
icache miss, another jump, and maybe a cycle here or there... 100
cycles at worst. And the benefit might also be larger than 0.1 cycle
because it could save some icache and reduce cold branch mispredicts.
It will also make the next gcc use jumps instead of cmov, which
reduces hazards to the out of order engine for example.

I think 1-5% is more reasonable a number if I were to pull one out of
my hat.

--
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/