Received: by 10.223.176.5 with SMTP id f5csp1892265wra; Wed, 31 Jan 2018 13:12:49 -0800 (PST) X-Google-Smtp-Source: AH8x224Ai8b0XWNCMsXjcpHUlOA6RyGaTpL+ss41BsrVsAr+N3sIPSwVdfhviP5VSAGh5THoI65G X-Received: by 2002:a17:902:6ac4:: with SMTP id i4-v6mr30222183plt.304.1517433169344; Wed, 31 Jan 2018 13:12:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517433169; cv=none; d=google.com; s=arc-20160816; b=vIbAr6aW0UIJDxStdeA3GbFY0NC/wa5H785KuyfqRJAmj1en9dSsgUWqWm5vo5gGwa dydQ0RovyGz90e/O6+ZnEqUT5aPAAn8TbsSsLTYRz845QBwty4alL+9yfWCzyEhDA/f5 JvWKzD9f0NvQaTO1EaMEYIYa+9tnnTS9vfU7s302SzZSRvmktksEtcW6g9yVya1zNqHL 0S9JVjTXOeLu0qKe+XVZL8RZA93E/WZYj6RITFUX9fHTmue/hlFVYJUNo3NZRCij1Zn6 OY1Rm86CX1vthYVMFWwI5gzzGfheVzKOqQfYLoeRtSy2ayfBL9wu67wDzzZMpPGUfqSm exKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature:arc-authentication-results; bh=oJihMbSv329xZqUUh8cyeg33cdpV4+DcZ0wc9eIhlHg=; b=yOWl/nHo9tNZt3bTar0Sf8ttn5caEnnN3Hd149jLv5wgrEpo+vK8N5AnYvXYVNq4y9 h6HVevix3bd8n9vJMMfu4KZs/6IiEb+p7ILEtBw++uDyoLeluSQzJ2NH70hijMt573p/ 225we9sXga8cH4+AznqVJvUOH0Hgyd+8/3X8sIRlawpTXhkq0gDAl7g8Awt8tKu5U4Le 1Yxs40PiYIVhSnv6Khqq133zu0FntxXLXY9SdBvPXqt1UWfk8EOd3ORIeSHsvpLoKvyT ZYjTPFPLAp+NOKtteUA0Cx2gShG6SJ+yY949kAQ+x86Dl/aDVWXI8C6jiD5bCO+x7Kms SPrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=aq4FKVz7; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o9-v6si113467pls.290.2018.01.31.13.12.34; Wed, 31 Jan 2018 13:12:49 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=aq4FKVz7; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752766AbeAaVJ3 (ORCPT + 99 others); Wed, 31 Jan 2018 16:09:29 -0500 Received: from mail-wm0-f44.google.com ([74.125.82.44]:51034 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751985AbeAaVJ1 (ORCPT ); Wed, 31 Jan 2018 16:09:27 -0500 Received: by mail-wm0-f44.google.com with SMTP id f71so1804178wmf.0 for ; Wed, 31 Jan 2018 13:09:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oJihMbSv329xZqUUh8cyeg33cdpV4+DcZ0wc9eIhlHg=; b=aq4FKVz7bPSlFh7NiIMLDlGLnXdDkL5kZwrwuM3B+jIfOSBr6FwJeYe6zYCfVPTGvd b3FKsOT0SaV2nZQykVy7ZBeg06NDQChzih+AcUBr+R7aVd7kf1kwULJf3ZPxCkQhyRyN Jd2M89lxOefjxpE0sb+k6vidjBznK2oYYJ/nqH8VhZTEq+t1TXmhHmVoCDvLSnXwfh3G DMkH6tJEAjOdBMxMho37O+nR3ylG+wuNEh5fK6uHzGhLP4oNzmzMzDnkFuOtGjb2o4Cw VpnIq42OrBJ3ryeGAtTxfu6x6Xl9gRlMqZQC5pK7eB3ukxOZFwLyruPCZBZKV8wL2Z9Y ICDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oJihMbSv329xZqUUh8cyeg33cdpV4+DcZ0wc9eIhlHg=; b=PkljtGB2tNZ7w95NK6GrJASaDZDkkUdd45OS4LfAQor1kT6K+Ut/hKUcZldtw5METN 5aTwMNdXylA2iC3nzmRTrojlWcKxK/K54SLU2F28kFi5QUuLiBjzUIvCAvdXr8xq6MIa qBJ/vtd9NZouPvOgRZSWUzDrB9o5JNeIC1pEL2IWkhORJhQI4YObuPHmGmIgtwS2tcwi mvKfOvJngMOtllKc8jKlJ+TdG5SXMJIxE+5LfTRoSjSjTFwZ5FFFjL9SdvrIegmpBHV1 9unpYJbmPPohvpxxQfWWtJHM4c6zqeHCEc5YWZxP9HANNZ2NUFzzfo2kXLx7D/g6JxL5 BNxg== X-Gm-Message-State: AKwxytfOb6cpuKn2PLg5SLKrBoQk1mVtibtJsJucsB2vTcZRMIV2qxE3 uTgqkxq00pFerRzSW8VCRuHL+7ej X-Received: by 10.80.167.65 with SMTP id h59mr32250254edc.78.1517432966459; Wed, 31 Jan 2018 13:09:26 -0800 (PST) Received: from [10.2.101.129] ([208.91.2.2]) by smtp.gmail.com with ESMTPSA id 6sm7591044edl.87.2018.01.31.13.09.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jan 2018 13:09:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] x86: Align TLB invalidation info From: Nadav Amit In-Reply-To: <8bb352bc-4e1f-4e87-80e3-a8e65d618d2a@linux.intel.com> Date: Wed, 31 Jan 2018 13:09:22 -0800 Cc: the arch/x86 maintainers , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , linux-kernel@vger.kernel.org, Peter Zijlstra , Andy Lutomirski Content-Transfer-Encoding: 7bit Message-Id: <0E65629C-0D7D-4602-A43D-B18E62F330A6@gmail.com> References: <20180131201118.1694-1-namit@vmware.com> <8bb352bc-4e1f-4e87-80e3-a8e65d618d2a@linux.intel.com> To: Dave Hansen X-Mailer: Apple Mail (2.3273) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dave Hansen wrote: > On 01/31/2018 12:11 PM, Nadav Amit wrote: >> The TLB invalidation info is allocated on the stack, which might cause >> it to be unaligned. Since this information may be transferred to >> different cores for TLB shootdown, this might result in an additional >> cache-line bouncing between the cores. >> >> GCC provides a way to deal with it by using >> __builtin_alloca_with_align(). Use it to avoid the bouncing cache lines. > > It doesn't really *bounce*, though, does it? I don't see any writes on > the remote side. The remote use seems entirely read-only. > > You also don't have to exhaustively test this, but I'd love to see at > least a sanity check with a microbenchmark (or something) that, yes, > this does help *something*. Maybe it makes the remote > flush_tlb_func_common() run faster because it's pulling in fewer lines, > or maybe you can even detect fewer misses in there. I agree that with the whole Meltdown/Spectre entry-cost it might not even be measurable, at least on small ( < 2 sockets) machines. But I do not think it worth profiling. Basically, AFAIK, all the data structures that are used for inter-processor communication by the kernel are aligned, and this is an exception.