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 > > >
