Re: [Qemu-devel] [PATCH 02/10] compiler.h: add QEMU_CACHELINE + QEMU_ALIGN() + QEMU_CACHELINE_ALIGNED

[Peter Maydell]

On 5 April 2016 at 18:24, Emilio G. Cota <address@hidden> wrote:
> On Tue, Apr 05, 2016 at 08:57:45 +0100, Peter Maydell wrote:
>> On 5 April 2016 at 06:30, Emilio G. Cota <address@hidden> wrote:
>> > +#define QEMU_CACHELINE (64)
>>
>> Why 64? Does anything bad happen if the host's cache line
>> size turns out to be greater than the value here ?
>
> Defining a number lower than the host's cache line could result
> in some false sharing. No big deal for most workloads.
>
> Defining a number greater than the host's cache might result in
> wasted memory, which we really should avoid.
>
> I used 64 because it is common on x86, which I assume is what most
> developers develop on.
>
> On Tue, Apr 05, 2016 at 17:29:05 +0200, Paolo Bonzini wrote:
>> But the size of data structures cannot change at run-time.  A bigger
>> worry is cross-compilation.
>>
>> Linux has these defaults:
>>
>>       Alpha   32 or 64
>>       ARM     configurable, 64 for ARMv7
>>       AArch64 128
>>       PPC     128
>>       s390    256
>>       x86     configurable, default 64
>>
>> which should be easy to copy in QEMU too.
>
> So how about this:
> we add these defaults, and also add an optional --configure
> parameter to override said defaults.

I think this definitely doesn't merit a configure parameter.

> Otherwise I'd just stick to 64.

If this is basically just a hashtable semi-tunable parameter knob,
then I don't mind if we use 64 everywhere (or some slightly more
architecture-aware default). But I would prefer that we not make
it a global define QEMU_CACHELINE if we can't actually guarantee
that it's the size of the cacheline (which we can't), because I
think that will be confusing and invite future misuse.

Unless we have another use case in the tree at the moment for
a number which is "probably the cacheline size, but might be
smaller or larger if you're unlucky", in which case we just want
a better name :-)

thanks
-- PMM