[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 02/10] compiler.h: add QEMU_CACHELINE + QEMU_ALI
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [PATCH 02/10] compiler.h: add QEMU_CACHELINE + QEMU_ALIGN() + QEMU_CACHELINE_ALIGNED |
Date: |
Tue, 5 Apr 2016 19:01:07 +0100 |
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
- [Qemu-devel] [PATCH 00/10] tb hash improvements, Emilio G. Cota, 2016/04/05
- Re: [Qemu-devel] [PATCH 02/10] compiler.h: add QEMU_CACHELINE + QEMU_ALIGN() + QEMU_CACHELINE_ALIGNED, Paolo Bonzini, 2016/04/05
- Re: [Qemu-devel] [PATCH 02/10] compiler.h: add QEMU_CACHELINE + QEMU_ALIGN() + QEMU_CACHELINE_ALIGNED, Lluís Vilanova, 2016/04/05
- Re: [Qemu-devel] [PATCH 02/10] compiler.h: add QEMU_CACHELINE + QEMU_ALIGN() + QEMU_CACHELINE_ALIGNED, Peter Maydell, 2016/04/05
- Re: [Qemu-devel] [PATCH 02/10] compiler.h: add QEMU_CACHELINE + QEMU_ALIGN() + QEMU_CACHELINE_ALIGNED, Paolo Bonzini, 2016/04/05
- Re: [Qemu-devel] [PATCH 02/10] compiler.h: add QEMU_CACHELINE + QEMU_ALIGN() + QEMU_CACHELINE_ALIGNED, Lluís Vilanova, 2016/04/05
- Re: [Qemu-devel] [PATCH 02/10] compiler.h: add QEMU_CACHELINE + QEMU_ALIGN() + QEMU_CACHELINE_ALIGNED, Richard Henderson, 2016/04/05
- Re: [Qemu-devel] [PATCH 02/10] compiler.h: add QEMU_CACHELINE + QEMU_ALIGN() + QEMU_CACHELINE_ALIGNED, Peter Maydell, 2016/04/05
- Re: [Qemu-devel] [PATCH 02/10] compiler.h: add QEMU_CACHELINE + QEMU_ALIGN() + QEMU_CACHELINE_ALIGNED, Lluís Vilanova, 2016/04/05
- Re: [Qemu-devel] [PATCH 02/10] compiler.h: add QEMU_CACHELINE + QEMU_ALIGN() + QEMU_CACHELINE_ALIGNED, Richard Henderson, 2016/04/05