On Tue, Sep 18, 2018 at 16:55:56 +0100, Peter Maydell wrote:
> On 11 September 2018 at 21:43, Emilio G. Cota <c...@braap.org> wrote:
> > On Tue, Sep 11, 2018 at 05:43:38 -0700, Richard Henderson wrote:
> >> 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.
>
> I guess the question I have is:
> * will we need (now or in future) to emit atomic accesses
> into generated TCG code that need to interoperate with
> the atomic accesses we do from C code ?
> * if so, does libatomic provide a mechanism for doing that?
>
> (maybe there's nothing you can do except to call out from
> the generated code to C code anyway)
We already have these. For instance:
- sTLB lookups can happen concurrently with invalidations
to the same sTLB from another core (via tlb_reset_dirty)
- icount_decr is written to by cpu_exit, and is read
at the beginning of each TB (with a tcg_gen_ld_32 generated
by gen_tb_start).
The latter is always a 32-bit access, so all hosts can generate
it atomically. The former can be a 64-bit access if the guest
is 64-bit, which cannot be done if !CONFIG_ATOMIC64. But we
already disable mttcg for those combinations (we define
TCG_OVERSIZED_GUEST for this).
If we wanted to support mttcg even for oversized guests,
then libatomic or our "atomic64" implementation could help,
but we'd have to insert a lock on every guest load/store
(either via the TCG backend or via a C helper). I do not think
we have enough users of these hosts to warrant support for this.
Moreover, these systems are unlikely to have many cores, and
therefore are unlikely to benefit much from mttcg.
Thanks,
Emilio
