From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za68U-0005I1-IY for qemu-devel@nongnu.org; Thu, 10 Sep 2015 13:59:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Za68P-0007EP-GH for qemu-devel@nongnu.org; Thu, 10 Sep 2015 13:59:50 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:35194) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za68P-0007EF-Cj for qemu-devel@nongnu.org; Thu, 10 Sep 2015 13:59:45 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C066720A19 for ; Thu, 10 Sep 2015 13:59:44 -0400 (EDT) Date: Thu, 10 Sep 2015 14:00:23 -0400 From: "Emilio G. Cota" Message-ID: <20150910180023.GC17236@flamenco> References: <1440375847-17603-1-git-send-email-cota@braap.org> <1440375847-17603-16-git-send-email-cota@braap.org> <87wpvy8i6p.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87wpvy8i6p.fsf@linaro.org> Subject: Re: [Qemu-devel] [RFC 15/38] radix-tree: add generic lockless radix tree module List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex =?iso-8859-1?Q?Benn=E9e?= Cc: mttcg@listserver.greensocs.com, mark.burton@greensocs.com, a.rigo@virtualopensystems.com, qemu-devel@nongnu.org, guillaume.delbergue@greensocs.com, pbonzini@redhat.com, Frederic Konrad On Thu, Sep 10, 2015 at 15:25:50 +0100, Alex Bennée wrote: > > Emilio G. Cota writes: > > > This will be used by atomic instruction emulation code. > > If we are adding utility functions into the code base like this (which I > can see being useful) we should at least add some documentation with > example calling conventions to docs/ Ack. > Have you any performance numbers comparing the efficiency of the radix > approach to a "dumb" implementation? I tried a few lazy solutions (meaning having to write less code, which isn't that dumb), such as having a g_hash_table protected by a mutex. But this means potential contention on that mutex, so that's not a better option. Whatever the solution might be, this is a slow path (only invoked on atomic ops or regular stores that affect lines previously accessed with atomic ops) so scalability is a more important goal than absolute speed. The big perf impact comes on x86 when instrumenting stores, which is orthogonal to this; invoking a helper on each store is a huge perf killer for some benchmarks. It's OK for others though, but I still think we should be able to do better. Thanks, Emilio