From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38386) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anVI9-0007NQ-0n for qemu-devel@nongnu.org; Tue, 05 Apr 2016 14:01:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anVI7-0005Er-Th for qemu-devel@nongnu.org; Tue, 05 Apr 2016 14:01:28 -0400 Received: from mail-vk0-x22f.google.com ([2607:f8b0:400c:c05::22f]:35774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anVI7-0005Em-NJ for qemu-devel@nongnu.org; Tue, 05 Apr 2016 14:01:27 -0400 Received: by mail-vk0-x22f.google.com with SMTP id e6so27963945vkh.2 for ; Tue, 05 Apr 2016 11:01:27 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160405172453.GA5796@flamenco> References: <5703D9C1.2090307@redhat.com> <20160405172453.GA5796@flamenco> From: Peter Maydell Date: Tue, 5 Apr 2016 19:01:07 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 02/10] compiler.h: add QEMU_CACHELINE + QEMU_ALIGN() + QEMU_CACHELINE_ALIGNED List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Emilio G. Cota" Cc: MTTCG Devel , MTTCG Devel , Peter Crosthwaite , QEMU Developers , Sergey Fedorov , Paolo Bonzini , =?UTF-8?B?QWxleCBCZW5uw6ll?= , Richard Henderson On 5 April 2016 at 18:24, Emilio G. Cota wrote: > On Tue, Apr 05, 2016 at 08:57:45 +0100, Peter Maydell wrote: >> On 5 April 2016 at 06:30, Emilio G. Cota 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