From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60906) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azoen-0001rO-DK for qemu-devel@nongnu.org; Mon, 09 May 2016 13:07:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1azoej-0003NX-9T for qemu-devel@nongnu.org; Mon, 09 May 2016 13:07:45 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:57864) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azoeg-0003Lw-Ss for qemu-devel@nongnu.org; Mon, 09 May 2016 13:07:41 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 839C62084C for ; Mon, 9 May 2016 13:07:28 -0400 (EDT) Date: Mon, 9 May 2016 13:07:27 -0400 From: "Emilio G. Cota" Message-ID: <20160509170727.GA12440@flamenco> References: <20160425152528.GA16402@flamenco> <1461627983-32563-1-git-send-email-cota@braap.org> <87shy8ev7c.fsf@linaro.org> <20160430034035.GA31609@flamenco> <573072CE.3070808@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573072CE.3070808@redhat.com> Subject: Re: [Qemu-devel] [RFC v3] translate-all: protect code_gen_buffer with RCU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Alex =?iso-8859-1?Q?Benn=E9e?= , QEMU Developers , MTTCG Devel , Peter Crosthwaite , Richard Henderson , Sergey Fedorov On Mon, May 09, 2016 at 13:21:50 +0200, Paolo Bonzini wrote: > On 30/04/2016 05:40, Emilio G. Cota wrote: > >> The tb_flush > >> > is a fairly rare occurrence its not like its on the critical performance > >> > path (although of course pathological cases are possible). > > This is what I thought from the beginning, but wanted to give this > > alternative a go anyway to see if it was feasible. > > > > On my end I won't do any more work on this approach. Will go back > > to locks, despite Paolo's (justified) dislike for them =) > > Which locks? tb_lock during tb_find_fast? The problem with that was > that it slowed down everything a lot, wasn't it? By "locks" I meant somehow forcing other threads/vcpus to stop, to then perform tb_flush. This can be achieved with a bunch of primitives such as condition variables (*gaaah*) -- these of course involve "locks" :P The removal of tb_lock() when looking up tb's is orthogonal to this. > To me, the RCU idea is not really about making tb_flush (the rare case) > faster; it was more about keeping the rest simple and fast. Well I agree with this idea; I wanted to see how far we could take it. E.