From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754489AbcB2MmF (ORCPT ); Mon, 29 Feb 2016 07:42:05 -0500 Received: from mail.efficios.com ([78.47.125.74]:38913 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752316AbcB2MmB (ORCPT ); Mon, 29 Feb 2016 07:42:01 -0500 Date: Mon, 29 Feb 2016 12:41:49 +0000 (UTC) From: Mathieu Desnoyers To: Arnd Bergmann Cc: Peter Zijlstra , Linus Torvalds , Ben Maurer , Thomas Gleixner , Ingo Molnar , Russell King , linux-api , Andrew Morton , Michael Kerrisk , Dave Watson , rostedt , Andy Lutomirski , Will Deacon , "Paul E. McKenney" , Chris Lameter , Andi Kleen , Josh Triplett , Paul Turner , Linux Kernel Mailing List , Catalin Marinas , Andrew Hunter , "H. Peter Anvin" Message-ID: <1811549980.11849.1456749709589.JavaMail.zimbra@efficios.com> In-Reply-To: <3364335.Bqf8sAzlTS@wuerfel> References: <1456270120-7560-1-git-send-email-mathieu.desnoyers@efficios.com> <1082926946.10326.1456619994590.JavaMail.zimbra@efficios.com> <20160229103221.GI6356@twins.programming.kicks-ass.net> <3364335.Bqf8sAzlTS@wuerfel> Subject: Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [78.47.125.74] X-Mailer: Zimbra 8.6.0_GA_1178 (ZimbraWebClient - FF44 (Linux)/8.6.0_GA_1178) Thread-Topic: getcpu_cache system call: cache CPU number of running thread Thread-Index: 83cRTikX5Pw47C2PzqV4ZjqiaKGR5g== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Feb 29, 2016, at 5:39 AM, Arnd Bergmann arnd@arndb.de wrote: > On Monday 29 February 2016 11:32:21 Peter Zijlstra wrote: >> On Sun, Feb 28, 2016 at 12:39:54AM +0000, Mathieu Desnoyers wrote: >> >> > /* This structure needs to be aligned cache line size. */ >> > struct thread_local_abi { >> > int32_t cpu_id; >> > uint32_t rseq_seqnum; >> > uint64_t rseq_post_commit_ip; >> > /* Add new fields at the end. */ >> > } __attribute__((packed)); >> >> I would really not use packed; that can lead to horrible layout. >> >> Suppose someone would add: >> >> uint32_t foo; >> uint64_t bar; >> >> With packed, you get an unaligned uint64_t in there, which is horrible. >> Without packed, you get a hole, which you can later fill. > Actually, Peter is wrong about the hole there. On some 32-bit architectures, 64-bit integers are aligned on 32-bit, not 64-bit. So there may or may not be a hole there, and that would lead to a mess. > What's making things worse is that on some architectures, adding > __packed will force access by bytes rather than just reading > a 32-bit or 64-bit numbers directly, so it's slow and non-atomic. Agreed that many architectures issue slower instructions when reading from packed structures, which is unwanted. Could we require that each field be naturally aligned and require that they are placed so _no_ padding whatsoever should ever be added by the compiler ? If that's possible, then we could remove the packed. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com