qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 02/12] util: add atomic64


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v2 02/12] util: add atomic64
Date: Tue, 18 Sep 2018 16:55:56 +0100

On 11 September 2018 at 21:43, Emilio G. Cota <address@hidden> 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)

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]