From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753167Ab2BVPNN (ORCPT ); Wed, 22 Feb 2012 10:13:13 -0500 Received: from merlin.infradead.org ([205.233.59.134]:60013 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751845Ab2BVPNM convert rfc822-to-8bit (ORCPT ); Wed, 22 Feb 2012 10:13:12 -0500 Message-ID: <1329923583.24994.21.camel@twins> Subject: Re: [PATCH 00/10] jump label: introduce very_[un]likely + cleanups + docs From: Peter Zijlstra To: Steven Rostedt Cc: Ingo Molnar , "H. Peter Anvin" , Jason Baron , mathieu.desnoyers@efficios.com, davem@davemloft.net, ddaney.cavm@gmail.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Linus Torvalds , rth Date: Wed, 22 Feb 2012 16:13:03 +0100 In-Reply-To: <1329918881.25686.92.camel@gandalf.stny.rr.com> References: <4F43F9F0.4000605@zytor.com> <20120222065016.GA16923@elte.hu> <4F44934B.2000808@zytor.com> <20120222072538.GA17291@elte.hu> <4F449ACF.3040807@zytor.com> <20120222074839.GA24890@elte.hu> <20120222080659.GA25318@elte.hu> <1329916920.25686.79.camel@gandalf.stny.rr.com> <20120222133404.GA14085@elte.hu> <1329918881.25686.92.camel@gandalf.stny.rr.com> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Evolution 3.2.2- Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2012-02-22 at 08:54 -0500, Steven Rostedt wrote: > But we could push a "unlikely(static_branch())" for > such a case (or keep it as very_unlikely()). If only that would work.. GCC assumes a bunch of things when you use 'asm goto'. An unbiased 'asm goto' that would take likely() and unlikely() hints would be ideal, but alas that's not how the thing got implemented. Now arguable we could maybe just stick with the static_branch() thing and decide that GCC is broken for adding bias and not respecting likely() and unlikely(), but the GCC folks might have an opinion there. Anyway, if we have to stick with the current implementation then an unbiased version is impossible to implement. If we get GCC folks on board to change stuff, who knows.