From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ7Kb-0001Ep-DF for qemu-devel@nongnu.org; Wed, 04 Feb 2015 16:17:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJ7KW-00085w-KT for qemu-devel@nongnu.org; Wed, 04 Feb 2015 16:17:53 -0500 Received: from mail-wg0-x22b.google.com ([2a00:1450:400c:c00::22b]:62041) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ7KW-00085o-Em for qemu-devel@nongnu.org; Wed, 04 Feb 2015 16:17:48 -0500 Received: by mail-wg0-f43.google.com with SMTP id y19so4154005wgg.2 for ; Wed, 04 Feb 2015 13:17:47 -0800 (PST) Sender: Paolo Bonzini Message-ID: <54D28C78.1070604@redhat.com> Date: Wed, 04 Feb 2015 22:17:44 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <54D2578B.4050605@redhat.com> <20150204210156.GA26445@flamenco> In-Reply-To: <20150204210156.GA26445@flamenco> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 0/3] rcu: add option to use upstream liburcu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Emilio G. Cota" Cc: qemu-devel@nongnu.org On 04/02/2015 22:01, Emilio G. Cota wrote: >> You're right, I was imprecise---I meant they are interoperable. You can >> use atomic_rcu_read/write together with liburcu, you do not need to use >> the liburcu-provided rcu_dereference/rcu_assign_pointer. > > It's true that they can coexist. I'm just not sold on having two ways > of doing the same thing. It would make more sense to me to only divert > from the original API if there's a good reason to do so -- otherwise > an eventual merge (say after option a) discussed below) would be more > painful than necessary. The good reason was to mimic the C11 atomic_load/atomic_store functions. >> As to call_rcu/call_rcu1, I understand there is a problem. Maybe call >> the QEMU versions rcu_call/rcu_call1? Then you can add simple wrappers >> if you want to use liburcu-mb. > > Again, adhering to the original API if possible makes more sense to me, to > prevent future confusion. Here the good reason is that QEMU's version of call_rcu is type-safe. > Better testing, (eventually) less work, less bugs, no code duplication, > ability to just merge new features from upstream. > > Essentially the usual reasons against forking a project. Agreed. >> QEMU hardly uses hash tables at all. > > I understand there's currently not much demand for these. I think however > they might become valuable in the future, provided we end up having > a multi-threaded TCG. > > If RCU's history in the linux kernel is of any guide, chances are RCU > will end up being used in more places than one could initially guess: > > http://www2.rdrop.com/~paulmck/techreports/RCUUsage.2013.02.24a.pdf Yes, that's possible. However, the "stupid coarse lock" strategy does not work too well for Linux because you have N processes banging on the same device or file system. QEMU has much higher separation between components: all the complicated stuff happens in the guest. > What I'm investigating now is how to do this in a manner that is palatable > to upstream. For this as it's well known we need a multi-threaded TCG, > and I believe quite a few bits from liburcu(-cds) might help to > get there. Are you using (or planning to use) a shared translated code cache, or a separate cache for each CPU? Paolo > So for now I'll keep the liburcu(-cds) compile option in my tree and > see how far I can get. Of course I'll keep fallback code using locks > in there so that we can measure the performance differences. > > Thanks, > > Emilio > > [1] https://github.com/cdkersey/qsim > > >