On 5 April 2016 at 18:24, Emilio G. Cota <c...@braap.org> wrote: > On Tue, Apr 05, 2016 at 08:57:45 +0100, Peter Maydell wrote: >> On 5 April 2016 at 06:30, Emilio G. Cota <c...@braap.org> 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
