From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752832AbcB2Klx (ORCPT <rfc822;w@1wt.eu>);
	Mon, 29 Feb 2016 05:41:53 -0500
Received: from mout.kundenserver.de ([212.227.17.13]:54801 "EHLO
	mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752054AbcB2Klu (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 29 Feb 2016 05:41:50 -0500
From: Arnd Bergmann <arnd@arndb.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
        Ben Maurer <bmaurer@fb.com>, Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Russell King <linux@arm.linux.org.uk>,
        linux-api <linux-api@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Michael Kerrisk <mtk.manpages@gmail.com>,
        Dave Watson <davejwatson@fb.com>, rostedt <rostedt@goodmis.org>,
        Andy Lutomirski <luto@amacapital.net>,
        Will Deacon <will.deacon@arm.com>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Chris Lameter <cl@linux.com>, Andi Kleen <andi@firstfloor.org>,
        Josh Triplett <josh@joshtriplett.org>, Paul Turner <pjt@google.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Andrew Hunter <ahh@google.com>, "H. Peter Anvin" <hpa@zytor.com>,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Subject: Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread
Date: Mon, 29 Feb 2016 11:39:34 +0100
Message-ID: <3364335.Bqf8sAzlTS@wuerfel>
User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; )
In-Reply-To: <20160229103221.GI6356@twins.programming.kicks-ass.net>
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>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Provags-ID: V03:K0:uBAt7PkRj80CefbXU/E0a/iYSouhxrA9B/ADcR4uk16ZK36Y1sX
 1Z1TjVFnturAZS6ynKOqjl38Zo8rJWJ+t184P7sPMNRExVMy13+2ADuh3/bE5YDhPF1MGJe
 KgM+vJqeIAo9rF6ntMKXFuZZPrWUp3n0WzDxG3n3RHW3gF/NnlFUtYo112q1GBtXiV541OA
 viH1lL9Ue0A7XIyFqTd/w==
X-UI-Out-Filterresults: notjunk:1;V01:K0:X9P5un8nrC4=:U5TF2Ro43IrkUyN55MFNju
 UpcCdKa1cE6ZR1adu4jW/QE8AiWxDdiM2nRxmsf6PYxvnXrtn1qB6/nkTLOtb4ZSkS0rUTv7R
 gfpZAJcyHNvA+9/KVBFVt62RozynrlxpRGBg9II9nI4IRZGRuMyf1fYG20ATTnV5q48cOthXa
 f2rqLBS0ImMF8ohv+UoyGOYZPcWM84I4wV2FNrzmrAbHaN+pjSVnNMEXhfDm0FeKBp7Yr90VX
 TNh68EMUNFMqeF14qDyxPOASzXC21egOg0Wj52ll1VnJ3sYI/Hmman3Ouei1r2vSRtuCQBuxi
 rpBtHjZwNHPY//vqCwgGHbLTps5E06w+HuMe26PyihSKjToBArHdYBEa9SFQIBGU8G19q/g3V
 dwWR6s6QuTcY9V4wZ4yvK7FqH93EbilR/auYcd2rZUK8IpY5FQbATT4gQXjeAi2gqFpclaqJ4
 FKHsvNJuw0kjdqtRRKmvlzjLeFEV1/iVKRrSahdkspOeIwfdtz1K36U1SIiaguRhFkcDuowa9
 KItVDbzl4T84w8k7WIXG/aePMxFkYvVEC+mZHzurKRhGfCfrtYYixYYWd5RrQFYcWgTNCW1/3
 BuD5mIPcLd046XG52n9CUt/cqE0+GB9N1iOXMbcDXuhmMzfaBDt8geEj9MaBUHrcYL7ybaE2k
 OFXQO7Bd7AiSAInsTUuZ+ZSujH4POod8VlXumaTJYCh+84PQ9SfiunvuvyabiEU6Wy2BeVqfN
 vIZTQggI9BjOwB6A
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

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.

	Arnd