[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 02/12] util: add atomic64
From: |
Emilio G. Cota |
Subject: |
Re: [Qemu-devel] [PATCH v2 02/12] util: add atomic64 |
Date: |
Tue, 18 Sep 2018 14:49:21 -0400 |
User-agent: |
Mutt/1.9.4 (2018-02-28) |
On Tue, Sep 18, 2018 at 10:23:32 -0300, Murilo Opsfelder Araujo wrote:
> On Tue, Sep 11, 2018 at 04:43:04PM -0400, Emilio G. Cota wrote:
> > On Tue, Sep 11, 2018 at 05:43:38 -0700, Richard Henderson wrote:
> > > On 09/10/2018 04:27 PM, Emilio G. Cota wrote:
> > > > +#define GEN_READ(name, type) \
> > > > + type name(const type *ptr) \
> > > > + { \
> > > > + QemuSpin *lock = addr_to_lock(ptr); \
> > > > + type ret; \
> > > > + \
> > > > + qemu_spin_lock(lock); \
> > > > + ret = *ptr; \
> > > > + qemu_spin_unlock(lock); \
> > > > + return ret; \
> > > > + }
> > > > +
> > > > +GEN_READ(atomic_read_i64, int64_t)
> > > > +GEN_READ(atomic_read_u64, uint64_t)
> > >
> > > Is there really a good reason to have two external
> > > functions instead of having one of them inline and
> > > perform a cast?
> >
> > Not really. I can do a follow-up patch if you want me to.
> >
> > > Is this any better than using libatomic?
> >
> > I didn't think of using libatomic. I just checked the source
> > code and it's quite similar:
> > - It uses 64 locks instead of 16 ($page_size/$cache_line,
> > but these are hard-coded for POSIX as 4096/64, respectively)
> > - We compute the cacheline size and corresponding padding
> > at run-time, which is a little better than the above.
> > - The locks are implemented as pthread_mutex instead of
> > spinlocks. I think spinlocks make more sense here because
> > we do not expect huge contention (systems without
> > !CONFIG_ATOMIC64 have few cores); for libatomic it makes
> > sense to use mutexes because it might be used in many-core
> > machines.
> >
> > So yes, we could have used libatomic. If you feel strongly
> > about it, I can give it a shot.
>
> Would allowing user to choose between libatomic or Emilio's implementation
> at configure time be a bad idea?
>
> One could pass, for example, --with-libatomic to configure script to use
> libatomic instead of using Emilio's implementation, which could be the
> default implementation - or vice-versa.
If we decide to use libatomic then there's no need to keep
our own atomic64. As I said in another message, both
implementations are very similar.
libatomic supports more operations, but at the moment
we only need 64-bit atomic_read/write.
Thanks,
Emilio
- [Qemu-devel] [PATCH v2 10/12] cpus: access .qemu_icount_bias with atomic64, (continued)
- [Qemu-devel] [PATCH v2 10/12] cpus: access .qemu_icount_bias with atomic64, Emilio G. Cota, 2018/09/10
- [Qemu-devel] [PATCH v2 12/12] configure: enable mttcg for i386 and x86_64, Emilio G. Cota, 2018/09/10
- [Qemu-devel] [PATCH v2 01/12] cacheinfo: add i/d cache_linesize_log, Emilio G. Cota, 2018/09/10
- [Qemu-devel] [PATCH v2 02/12] util: add atomic64, Emilio G. Cota, 2018/09/10
- Re: [Qemu-devel] [PATCH v2 02/12] util: add atomic64, Richard Henderson, 2018/09/11
- Re: [Qemu-devel] [PATCH v2 02/12] util: add atomic64, Peter Maydell, 2018/09/18
- Re: [Qemu-devel] [PATCH v2 02/12] util: add atomic64, Emilio G. Cota, 2018/09/18
- Re: [Qemu-devel] [PATCH v2 02/12] util: add atomic64, Peter Maydell, 2018/09/18
- Re: [Qemu-devel] [PATCH v2 02/12] util: add atomic64, Richard Henderson, 2018/09/18
[Qemu-devel] [PATCH v2 06/12] atomic: fix comment s/x64_64/x86_64/, Emilio G. Cota, 2018/09/10
[Qemu-devel] [PATCH v2 05/12] test-rcu-list: access n_reclaims and n_nodes_removed with atomic64, Emilio G. Cota, 2018/09/10
[Qemu-devel] [PATCH v2 07/12] cpus: initialize timers_state.vm_clock_lock, Emilio G. Cota, 2018/09/10
[Qemu-devel] [PATCH v2 04/12] qsp: use atomic64 accessors, Emilio G. Cota, 2018/09/10