Re: [Qemu-devel] [PATCH 0/3] rcu: add option to use upstream liburcu

[Paolo Bonzini <pbonzini@redhat.com>]

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