linux-kernel - Re: [RFC][PATCH 3/2] x86/jump labels: Count and display the short jumps used

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]

Date:	Wed, 7 Aug 2013 14:56:26 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jason Baron <jbaron@...mai.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC][PATCH 3/2] x86/jump labels: Count and display the short
 jumps used

On Wed, Aug 7, 2013 at 2:37 PM, Jason Baron <jbaron@...mai.com> wrote:
>
> ok - I can see 2 variants here as you mentioned:
>
> 1) 'Unbiased' - we want to treat both branches equally but don't want
> the load/test/jmp sequence. For things like the scheduler stats.
>
> 2) 'Biased' - where the unlikely path is moved completely out-of-line.
> And we have a strong 'bias' to optimize the default path.

Actually, personally I'd much rather see *three* cases, and for the
static keys usually only two are relevant:

 - truly unbiased: a normal conditional that we don't really know
which one is the likely or unlikely path

   This is likely *not* the normal case for a static key, since almost
always we have a lightweight case, and a heavy one. Most of the static
keys are about things like statistics, which are inherently more
expensive than not having statistics, so they aren't really
"unbiased". There's a bias introduced by one side being more costly
than the other. You want the light (non-statistics) case to be a
fall-through, while the heavy case is going to be much more expensive
and update global variables etc.

 - "slightly biased". The normal kind of "unlikely()", where you want
to have one side of the branch be the fall-through and common case
that doesn't interrupt the I$ prefetch etc. This is the likely case
for most static key use, I think.

 - "strongly biased": a "very unlikely" kind of thing, which is either
a major exception case (ie an assertion on BUG_ON() or other basically
fatal thing), or is something like the tracing code that is uncommon
and where we want basically minimal impact when it is not enabled, but
when it's on, the impact is so big that the conditional branch no
longer even matters.

The first one really doesn't care which way a branch goes. The second
one prefers a fall-through case for the common case. And the third one
is basically a "get this code away from me".

Both of the biased cases *might* also want things like "save register
state in the unlikely path so that the *likely* path doesn't have to".
Think things like "it's a leaf function, and the likely path doesn't
need any temporaries, but the unlikely path ends up doing function
calls and needs a stack frame". If the compiler can make likely path
avoid the stack frame generation and be straight-line, that would be
really nice.

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