Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933197AbbGUQMZ (ORCPT <rfc822;w@1wt.eu>);
	Tue, 21 Jul 2015 12:12:25 -0400
Received: from casper.infradead.org ([85.118.1.10]:42285 "EHLO
	casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753084AbbGUQMY (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 21 Jul 2015 12:12:24 -0400
Date: Tue, 21 Jul 2015 18:12:15 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Thomas Gleixner <tglx@linutronix.de>, Jason Baron <jasonbaron0@gmail.com>,
        Mikulas Patocka <mpatocka@redhat.com>,
        Paul Mackerras <paulus@samba.org>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Kees Cook <keescook@chromium.org>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Vince Weaver <vince@deater.net>, "hillf.zj" <hillf.zj@alibaba-inc.com>,
        Valdis Kletnieks <Valdis.Kletnieks@vt.edu>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Borislav Petkov <bp@alien8.de>, Steven Rostedt <rostedt@goodmis.org>
Subject: Re: Kernel broken on processors without performance counters
Message-ID: <20150721161215.GU19282@twins.programming.kicks-ass.net>
References: <alpine.LRH.2.02.1507081000540.5217@file01.intranet.prod.int.rdu2.redhat.com>
 <20150708160750.GQ19282@twins.programming.kicks-ass.net>
 <CALCETrVqeG=3sKJv=pe9ZfaeRmx9uz+jNmXGmPu-7Hah4NvYDQ@mail.gmail.com>
 <559D8250.8000707@gmail.com>
 <CALCETrUb8tjDLQHF3q=_F7JRXhC8iEHW9o2xFsUbqsmyEOAiCQ@mail.gmail.com>
 <20150710141359.GJ19282@twins.programming.kicks-ass.net>
 <20150721082107.GE18673@twins.programming.kicks-ass.net>
 <alpine.DEB.2.11.1507211726040.18576@nanos>
 <20150721154959.GS19282@twins.programming.kicks-ass.net>
 <CALCETrWwy777nYTVpOn8Hs1JRG5nDyvky9B11otDRAid1L19vg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALCETrWwy777nYTVpOn8Hs1JRG5nDyvky9B11otDRAid1L19vg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1319
Lines: 51

On Tue, Jul 21, 2015 at 08:51:51AM -0700, Andy Lutomirski wrote:
> To clarify my (mis-)understanding:
> 
> There are two degrees of freedom in a static_key.  They can start out
> true or false, and they can be unlikely or likely.  Are those two
> degrees of freedom in fact tied together?

Yes, if you start out false, you must be unlikely. If you start out
true, you must be likely.

We could maybe try and untangle that if there really is a good use case,
but this is the current state.

The whole reason this happened is because 'false' is like:


	...
	<nop>
1:
	...



label:
	<unlikely code>
	jmp 1b


Where the code if out-of-line by default. The enable will rewrite the
<nop> with a jmp label.

Of course, if you have code that is on by default, you don't want to pay
that out-of-line penalty all the time. So the on by default generates:


	...
	<nop>
	<likely code>
label:
	...


Where, if we disable, we replace the nop with jmp label.

Or rather, that all is the intent, GCC doesn't actually honour hot/cold
attributes on asm labels very well last time I tried.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/