Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753982AbbGXMgy (ORCPT ); Fri, 24 Jul 2015 08:36:54 -0400 Received: from casper.infradead.org ([85.118.1.10]:36736 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753566AbbGXMgw (ORCPT ); Fri, 24 Jul 2015 08:36:52 -0400 Date: Fri, 24 Jul 2015 14:36:43 +0200 From: Peter Zijlstra To: Jason Baron Cc: Borislav Petkov , Andy Lutomirski , Thomas Gleixner , Mikulas Patocka , Paul Mackerras , Arnaldo Carvalho de Melo , Kees Cook , Andrea Arcangeli , Vince Weaver , "hillf.zj" , Valdis Kletnieks , "linux-kernel@vger.kernel.org" , Steven Rostedt Subject: Re: Kernel broken on processors without performance counters Message-ID: <20150724123643.GL18673@twins.programming.kicks-ass.net> References: <20150721181553.GA3378@nazgul.tnic> <55AE9471.1000601@gmail.com> <20150722042403.GA6345@nazgul.tnic> <55AFCDA4.5010406@gmail.com> <20150723104215.GH25159@twins.programming.kicks-ass.net> <55B0F808.2060302@gmail.com> <20150723143308.GD19282@twins.programming.kicks-ass.net> <20150723144930.GK18673@twins.programming.kicks-ass.net> <55B13D05.9050304@gmail.com> <20150724105602.GF19282@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150724105602.GF19282@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3169 Lines: 92 On Fri, Jul 24, 2015 at 12:56:02PM +0200, Peter Zijlstra wrote: > On Thu, Jul 23, 2015 at 03:14:13PM -0400, Jason Baron wrote: > > > +static enum jump_label_type jump_label_type(struct jump_entry *entry) > > > +{ > > > + struct static_key *key = static_key_cast(iter->key); > > > + bool true_branch = jump_label_get_branch_default(key); > > > + bool state = static_key_enabled(key); > > > + bool inv = static_key_inv(iter->key); > > > + > > > + return (true_branch ^ state) ^ inv; > > > > iiuc...this allows both the old style keys to co-exist with the > > new ones. IE state wouldn't be set for the new ones. And inv > > shouldn't be set for the old ones. Is that correct? > > @state is the dynamic variable here, the other two are compile time. > @true_branch denotes the default (compile time) value, and @inv denotes > the (compile time) branch preference. Ha!, so that wasn't entirely correct, it turned out @inv means arch_static_branch_jump(). That would let us remove the whole argument to the arch functions. That said, I generated the logic table for @inv meaning the branch type and then found a logic similar to what you outlined: /* * Combine the right initial value (type) with the right branch order * to generate the desired result. * * * type likely (1) unlikely (0) * -----------+-----------------------+------------------ * | | * true (1) | ... | ... * | NOP | JMP L * | | 1: ... * | L: ... | * | | * | | L: * | | jmp 1b * | | * -----------+-----------------------+------------------ * | | * false (0) | ... | ... * | JMP L | NOP * | | 1: ... * | L: ... | * | | * | | L: * | | jmp 1b * | | * -----------+-----------------------+------------------ * * The initial value is encoded in the LSB of static_key::entries, * type: 0 = false, 1 = true. * * The branch type is encoded in the LSB of jump_entry::key, * branch: 0 = unlikely, 1 = likely. * * This gives the following logic table: * * enabled type branch instuction * -----------------------------+----------- * 0 0 0 | NOP * 0 0 1 | JMP * 0 1 0 | NOP * 0 1 1 | JMP * * 1 0 0 | JMP * 1 0 1 | NOP * 1 1 0 | JMP * 1 1 1 | NOP * */ This gives a map: ins = enabled ^ branch, which shows @type to be redundant. And we can trivially switch over the old static_key_{true,false}() to emit the right branch type. Whcih would mean we could remove the type encoding entirely, but I'll leave that be for now, maybe it'll come in handy later or whatnot. -- 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/