From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:45590)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <cota@braap.org>) id 1ZUMpO-0005em-IF
	for qemu-devel@nongnu.org; Tue, 25 Aug 2015 18:36:27 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <cota@braap.org>) id 1ZUMpL-0002bB-Cx
	for qemu-devel@nongnu.org; Tue, 25 Aug 2015 18:36:26 -0400
Received: from out3-smtp.messagingengine.com ([66.111.4.27]:48914)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <cota@braap.org>) id 1ZUMpL-0002b7-8r
	for qemu-devel@nongnu.org; Tue, 25 Aug 2015 18:36:23 -0400
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46])
	by mailout.nyi.internal (Postfix) with ESMTP id 1E71E2148A
	for <qemu-devel@nongnu.org>; Tue, 25 Aug 2015 18:36:23 -0400 (EDT)
Date: Tue, 25 Aug 2015 18:36:46 -0400
From: "Emilio G. Cota" <cota@braap.org>
Message-ID: <20150825223646.GA8026@flamenco>
References: <1440375847-17603-1-git-send-email-cota@braap.org>
	<55DA7AF8.6040006@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <55DA7AF8.6040006@redhat.com>
Subject: Re: [Qemu-devel] [RFC 00/38] MTTCG: i386, user+system mode
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: mttcg@greensocs.com, mark.burton@greensocs.com, a.rigo@virtualopensystems.com, qemu-devel@nongnu.org, guillaume.delbergue@greensocs.com, alex.bennee@linaro.org, Frederic Konrad <fred.konrad@greensocs.com>

On Sun, Aug 23, 2015 at 19:01:28 -0700, Paolo Bonzini wrote:
> >   * tb_flush: do it once all other CPUs have been put to sleep by calling
> >     rcu_synchronize().
> >     We also instrument tb_lock to make sure that only one tb_flush request can
> >     happen at a given time.
> 
> What do you think about just protecting code_gen_buffer with RCU?

I'm not sure of what you mean. Isn't essentially that what the
mechanism I sent (cpu_tcg_sched_work) is doing? I mean, the assumption
is: if any thread is on an RCU read critical section, then code_gen_buffer
cannot be modified. That's why tb_flush is only called after
rcu_synchronize() returns, to make sure that no existing threads
are executing code from the buffer.

		Emilio