From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753387AbbCBIGM (ORCPT ); Mon, 2 Mar 2015 03:06:12 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:34152 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750834AbbCBIGI (ORCPT ); Mon, 2 Mar 2015 03:06:08 -0500 Date: Mon, 2 Mar 2015 09:05:44 +0100 From: Peter Zijlstra To: Michel Lespinasse Cc: mingo@kernel.org, rusty@rustcorp.com.au, mathieu.desnoyers@efficios.com, oleg@redhat.com, paulmck@linux.vnet.ibm.com, linux-kernel@vger.kernel.org, andi@firstfloor.org, rostedt@goodmis.org, tglx@linutronix.de, Andrea Arcangeli , David Woodhouse , Rik van Riel Subject: Re: [RFC][PATCH 7/9] rbtree: Implement generic latch_tree Message-ID: <20150302080544.GZ5029@twins.programming.kicks-ass.net> References: <20150228212447.381543289@infradead.org> <20150228213110.248177252@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 On Sun, Mar 01, 2015 at 01:17:15PM -0800, Michel Lespinasse wrote: > On Sat, Feb 28, 2015 at 1:24 PM, Peter Zijlstra wrote: > > Implement a latched RB-tree in order to get RCU style lookups. > > Looks fine to me. > > I wanted to ask, you are writing this as a generic layer even though > there is a single use at the moment; do you anticipate this will get > more usage soon ? I may have more comments if I knew what those may be > (it's probably all fine if the rate of changes is very low such as > with module load/unload, but I'm not sure what else you have in mind). It was more an exercise in separation in order to better document the various parts of this solution. That said, we could maybe also use this for uprobes. Uprobes have a global RB tree and every lookup is currently serialized by a spinlock. I've not yet heard that its really painful, but I imagine a heavy uprobe workload on big machines will eventually hurt. And through the years there have been 'demands' for RCU RB-trees, so maybe there's more potential users out there. Note that while the update is more expensive than with a single tree, its still of the same complexity, so its not horrendously more expensive.