From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751810AbbCSU7F (ORCPT ); Thu, 19 Mar 2015 16:59:05 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:55929 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751432AbbCSU6f (ORCPT ); Thu, 19 Mar 2015 16:58:35 -0400 Date: Thu, 19 Mar 2015 13:58:33 -0700 From: Andrew Morton To: Peter Zijlstra Cc: mingo@kernel.org, rusty@rustcorp.com.au, mathieu.desnoyers@efficios.com, oleg@redhat.com, paulmck@linux.vnet.ibm.com, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, andi@firstfloor.org, rostedt@goodmis.org, tglx@linutronix.de, Michel Lespinasse , Andrea Arcangeli , David Woodhouse , Rik van Riel Subject: Re: [PATCH 6/8] rbtree: Implement generic latch_tree Message-Id: <20150319135833.5a844744936bd8fdafea7ed5@linux-foundation.org> In-Reply-To: <20150319072502.GR23123@twins.programming.kicks-ass.net> References: <20150318133626.526984618@infradead.org> <20150318134631.939369528@infradead.org> <20150318221446.14b0b04d.akpm@linux-foundation.org> <20150319072502.GR23123@twins.programming.kicks-ass.net> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 19 Mar 2015 08:25:02 +0100 Peter Zijlstra wrote: > On Wed, Mar 18, 2015 at 10:14:46PM -0700, Andrew Morton wrote: > > On Wed, 18 Mar 2015 14:36:32 +0100 Peter Zijlstra wrote: > > > > > include/linux/rbtree_latch.h | 223 +++++++++++++++++++++++++++++++++++++++++++ > > > > Did it really need to all be inlined? > > Without that you get actual function calls to the less() and comp() > operators. This way GCC can inline the lot even though its function > pointers. > > The typical RB tree user open-codes all this every single time. Is it a good tradeoff? > > How much of this code is unneeded on uniprocessor? > > None, UP has NMIs too. OK. This code is basically required to support perf/ftrace and modules, yes? Presumably small and space-constrained systems aren't using either, so they don't take the hit. However CONFIG_MODULES systems which aren't using perf/ftrace _do_ take a hit. How many systems are we talking here? All non-x86?