Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933296AbbGUQ5M (ORCPT <rfc822;w@1wt.eu>);
	Tue, 21 Jul 2015 12:57:12 -0400
Received: from mail-qk0-f172.google.com ([209.85.220.172]:36325 "EHLO
	mail-qk0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S933120AbbGUQ5K (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 21 Jul 2015 12:57:10 -0400
Message-ID: <55AE79E4.5090600@gmail.com>
Date: Tue, 21 Jul 2015 12:57:08 -0400
From: Jason Baron <jasonbaron0@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Peter Zijlstra <peterz@infradead.org>,
        Andy Lutomirski <luto@amacapital.net>
CC: Thomas Gleixner <tglx@linutronix.de>,
        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
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> <20150721161215.GU19282@twins.programming.kicks-ass.net>
In-Reply-To: <20150721161215.GU19282@twins.programming.kicks-ass.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2415
Lines: 76



On 07/21/2015 12:12 PM, Peter Zijlstra wrote:
> 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.

We could potentially allow all combinations but it requires a more
complex implementation. Perhaps, by rewriting no-ops to jmps
during build-time? Steve Rostedt posted an implementation a while
back to do that, but in part it wasn't merged due to its
complexity and the fact that it increased the kernel text, which
I don't think we ever got to the bottom of. Steve was actually
trying to reduce the size of the no-ops by first letting the compiler
pick the 'jmp' instruction size (short jumps of only 2-bytes on
x86, instead of the hard-coded 5 bytes we currently have).
However, we could use the same idea here to allow the mixed
branch label and initial variable state.

That said, it seems easy enough to reverse the direction of
the branch in an __init or so when we boot, if required.

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

I tried this too not that long ago, and didn't seem to make any
difference. Ideally this could allow us to make variations where
'cold' code is moved further out-of-line.

Thanks,

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