From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54527) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anWQ7-0001HM-Bx for qemu-devel@nongnu.org; Tue, 05 Apr 2016 15:13:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anWQ4-0006fh-4c for qemu-devel@nongnu.org; Tue, 05 Apr 2016 15:13:47 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:42444) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anWQ3-0006fc-UH for qemu-devel@nongnu.org; Tue, 05 Apr 2016 15:13:44 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 076232083F for ; Tue, 5 Apr 2016 15:13:42 -0400 (EDT) Date: Tue, 5 Apr 2016 15:13:41 -0400 From: "Emilio G. Cota" Message-ID: <20160405191341.GA27828@flamenco> References: <5703D9C1.2090307@redhat.com> <20160405172453.GA5796@flamenco> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Peter Maydell Cc: MTTCG Devel , MTTCG Devel , Peter Crosthwaite , QEMU Developers , Sergey Fedorov , Paolo Bonzini , Alex =?iso-8859-1?Q?Benn=E9e?= , Richard Henderson On Tue, Apr 05, 2016 at 19:01:07 +0100, Peter Maydell wrote: > On 5 April 2016 at 18:24, Emilio G. Cota wrote: > > 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. Agreed :) > > 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 :-) Ok, so for now I'll only leave the ALIGN() macro, and then use ALIGN(64) in the hash table. We can always reconsider adding a more proper definition if this gets widespread use. Thanks, Emilio