Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753442AbbGWOd1 (ORCPT ); Thu, 23 Jul 2015 10:33:27 -0400 Received: from casper.infradead.org ([85.118.1.10]:44790 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752669AbbGWOdT (ORCPT ); Thu, 23 Jul 2015 10:33:19 -0400 Date: Thu, 23 Jul 2015 16:33:08 +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: <20150723143308.GD19282@twins.programming.kicks-ass.net> References: <20150721154959.GS19282@twins.programming.kicks-ass.net> <20150721161215.GU19282@twins.programming.kicks-ass.net> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55B0F808.2060302@gmail.com> 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: 1547 Lines: 31 On Thu, Jul 23, 2015 at 10:19:52AM -0400, Jason Baron wrote: > > And I think it'll all work. Hmm? > > Cool. This also gives an extra degree of freedom in that it allows keys to > be arbitrarily mixed with the likely/unlikely branch types. I'm not sure that's > come up as a use-case, but seems like it would be good. It also implies > that the LABEL_TYPE_{TRUE,FALSE}, is no longer associated with the key > b/c a key could be used in both and unlikely() or likely() branch. So that > would eventually go away, and the 'struct static_key()', I guess could point > to its relevant entries in both tables. Although, that means an extra > pointer in the 'struct static_key'. It may be simpler to simply add another > field to the jump table that specifies if the branch is likely/unlikely, > and then we are back to one table? IE arch_static_branch() could add > that field to the jump table. Way ahead of you, while implementing the dual section I ran into trouble and found that it would be far easier to indeed stick it in the jump_entry. However, instead of growing the thing, I've used the LSB of the key field, that's a pointer so it has at least two bits free anyhow. I've also implemented it for all archs (+- compile failures, I've not gotten that far). Lemme finish this and I'll post it. -- 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/