From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A578CE79AB for ; Wed, 20 Sep 2023 07:44:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E30A06B0125; Wed, 20 Sep 2023 03:44:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE0E16B0126; Wed, 20 Sep 2023 03:44:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CAA0E6B0127; Wed, 20 Sep 2023 03:44:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BB9F36B0125 for ; Wed, 20 Sep 2023 03:44:40 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 8E12C1A08A3 for ; Wed, 20 Sep 2023 07:44:40 +0000 (UTC) X-FDA: 81256188720.18.46F0BE7 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf24.hostedemail.com (Postfix) with ESMTP id 9660F18000E for ; Wed, 20 Sep 2023 07:44:38 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GT8MEvUb; spf=pass (imf24.hostedemail.com: domain of mingo.kernel.org@gmail.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695195878; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=XzT+Xiw8JySJKyD7hHrg/jFpbzpL9ozxt4Lqd8Kjts4=; b=8Lqe07Kpo8gn93TEmmJgFQ7aizAFuFdAsmzukmjNf9cESdU9MzZGR4AKejLOicBtb8DFuR 6tjV15vtJGyzVwrDX1c6SpexHTSMdmJ06coLCLuyYa6xrhE0ERunMbaXkR44+BsVAQFm6W qHDgMsLMrEb7rGiFa/YD5B64r3O9uGs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695195878; a=rsa-sha256; cv=none; b=uzBqVrztWv6Ls7vMtfOTC7BCoOFAi3gwoaAnKU/mTHpgTF+VDNa7MCzVo4adnftfZ9xE/Q ALHoWOUxCJnCPwChFYBKOshrAwjaMH3XP+2g3fFZrrSvNpPODS4R109/BtC/bC320TSdnQ wXieW9nGj6WP/4iC9U2quuXKHaz0wrg= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GT8MEvUb; spf=pass (imf24.hostedemail.com: domain of mingo.kernel.org@gmail.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-402c46c49f4so68896985e9.1 for ; Wed, 20 Sep 2023 00:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695195877; x=1695800677; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=XzT+Xiw8JySJKyD7hHrg/jFpbzpL9ozxt4Lqd8Kjts4=; b=GT8MEvUbSMzDGDGiw2DhL4Jsn74GbjgBniyL0uZAsinAH1rKtFxN5ttyHaNY2aeQb7 5C04OzJlG4th6gmOphmPR8mgOEDps3p9ZgI5Ny4vxeVwouZtzbPryH7JNeDsuu1ybhUc nVcAdpSrjmUYUAqcG+Szfqvpt+g2/S7VkerIIcWf5ltdlHZCI6F0tlsyeFpP14s9q2aQ QKtdl1N6GHQmPPacXIMxlyXjIrkKqBCRZWJIfpR1ELKZx619MBfPRqCYDWnHoLl7hQW7 nqZWpx3GR1djUN2yhEuLlsXPriUD4emAqfdwhMr1bzGqguMt5AU0HZWzSW03ARkNQk5q Ajhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695195877; x=1695800677; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=XzT+Xiw8JySJKyD7hHrg/jFpbzpL9ozxt4Lqd8Kjts4=; b=DvyqPBD2pe01v2ZWC3RdyZE9aMuyNh80er3kbSU5u1vrIQWUKfbzwMdxX67v81FVwM cfXw/FCk0pjOfQFIR3Nm/tlvyy2GoVw9WxZ30MYaXeBZjY+8CZFR2UwX9eCsV68/j3dj Pfev3NX4QL2xnAyuiT/A23TTjJJyWXMdsY/z2KhrFvNVhulPTgs2Rwg5SjEpCU7nO8nn vQN2FenjnR2Hd15ftbnrUgclwV5/q/dEk48y2rU8ogsnzFH4/fe8bONyKLP/00g6DqWB mbSTRR44OTO+8LgqoE6vQXV1fKgWZ4Hl6oMZvkQEtEk78yCK2Tzb6pGrXsP+JPUFFar5 A2jw== X-Gm-Message-State: AOJu0Yz2H3G+vTB2xaSmJ/WAujvWsDY55BMICzSwxUsVASWSVUL1Z/mH CMvf8QgOtwb3rUKl3YXQ8wY= X-Google-Smtp-Source: AGHT+IGGJqNN92cz5c7adAH7+BYpcEYHIa0hDUrWov+ACoikEcq6k5usOPuqM5OZepDWyc7c5KEP/w== X-Received: by 2002:a1c:ed08:0:b0:405:1bbd:aa9c with SMTP id l8-20020a1ced08000000b004051bbdaa9cmr1709320wmh.34.1695195876972; Wed, 20 Sep 2023 00:44:36 -0700 (PDT) Received: from gmail.com (1F2EF265.nat.pool.telekom.hu. [31.46.242.101]) by smtp.gmail.com with ESMTPSA id f7-20020adff987000000b0031c8a43712asm17606651wrr.69.2023.09.20.00.44.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Sep 2023 00:44:36 -0700 (PDT) Date: Wed, 20 Sep 2023 09:44:33 +0200 From: Ingo Molnar To: Matteo Rizzo Cc: "Lameter, Christopher" , Dave Hansen , penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, vbabka@suse.cz, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, keescook@chromium.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, corbet@lwn.net, luto@kernel.org, peterz@infradead.org, jannh@google.com, evn@google.com, poprdi@google.com, jordyzomer@google.com, Linus Torvalds Subject: Re: [RFC PATCH 00/14] Prevent cross-cache attacks in the SLUB allocator Message-ID: References: <20230915105933.495735-1-matteorizzo@google.com> <7a4f5128-28fd-3c5f-34c2-1c34f4448174@intel.com> <1d7573c0-ebbc-6ed2-f152-1045eb0542f9@os.amperecomputing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: pp3geytmikuhm8znxfi56p631t948ojp X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 9660F18000E X-Rspam-User: X-HE-Tag: 1695195878-104545 X-HE-Meta: U2FsdGVkX18t+FyXP8Wx2VOwOuC1Kely4rYi5O4sJVp9lngK7PdeUp8Afry4xwNe5hoHPX5sY3L+amb8URsnnCnNkzXoS0QI6QA8R/P7rMWj+vNgmN/KEGaPmXUSY+tDBN/K3CbqjdDnsnSmSbKrMj70MQ+8Yrh9tbsHc9KxbUqtwRXHng6xsP3Erfhko7MNfzy99R9h9Sv5WQXL03uj7K3fY/wDwlBSadZ7mvi8w2jnA3aLxHLdZwqFXOtAXRlVWPXsOR382IT+QFN52arncw8LRfv1vqC5Hc0OCjt/aBHbpRxdi3q4EUvX+mBVcPxt6KmvK1QO3DP3pjaMbFCK6bqGb2LGVgAlNSoIux+KNgjMHgWcMO5gFbsByxMcxMchwuS7ILwRSqOoWPWby4INLFpV4L9hk2u6tqT1TnHUGGMAqO9Ip04iZpiuaiEa1+GChat1l6jmR/mTIbmV6oNYTgFu7wT8gfdYERQ49hYksTiLebx2tXhkcgr2eAUJ8vdrnrnn2lj0rm1RVPNnKIjbTH9MqRq8Hw8tFRAo4IfHaDCRwIsnIVBzoPsXiBT/kOrTqIEinvKluSBWQac63y2FAhWoB0kYrdNFxJtsExr4bZo3+rSx9oWIE0/C7e8mwV64v836Ws09zVt+fA/6PbSrdbUogPsZmYOv86oiXDF7EEn29aYpS6LMvFpGBJqrQxB6DfqORKlvrlRZEwYDEUXxqK1McTd3a1tbwqGI1+voLrLhCXj5y22JCDr8e47KjMWsJJoyoBs7v7qPp85zsODuYSyMw/ML2Jzrw1noRfOchKirMC4sgjUhs2xz+rcQuGMzPr6hWjAt2pXaW/7P6kmqSN/KE9/sShqvejOD4u841UyCvsrT+fOrbh8+zqjJU2qxHh9DQQIW4SUl5BSv7bEVYG3M9UPXLNSn93j5G5s7bXlbWcErvAaKVD1c5U7CDauoUhe8pywLi0S9CsLUpI6 vd5UgDyz xWy9fFyi2PTP0fx3NkhEuWasdrohfH3Ms745lYIIfHuq6M22aMwkmjSVaG525dbBcISzJaJEaIhzQ1qNspY6DtqVx5QmyKs+ytZdjueggku5nZOHPrlOs5YFeaOIKP1fPl/LWdutveXqJdMJTj8lnFQqZKuVXSV7diAn4nbKp/nb0/3W6PQDycxWkdKryc2oc4Ft6eeXSgD1GOe4qckTBaDXwJniuI6e+HHT0EkOmXknwF+FqA/6acAWDNTtvEO/Nsig9EIiiG60cgCeOhFDdx36Tz+qV1/KEZDtWDn7EBpV4r/ozqOt/gDv0aug5d1LBdSX5mXMdSCONGRdKXDQIuZ8rCw3N5gQjqOKGTB2XkcST304y3Wca8iCPhz5tTY5OphaOqhQtl2qWH/ohX+0OM5+bzxHq9BmeZwWSyh65wueoiun5nedGUyy7YFTOhj2Eh+NugDSD2vbA5wWeq+1kOOhQBpfHIljMsZW9wqOipOjqLwcw2Eq1/p4UimpHklVmsIXJIf0xnPySysm2FbvaJKERHk6n4z+EE5Rgq7X04vTblx2BWfmJRp7+UJSr/YPpnPJOIehOi495g29i9/mN0c3LIX3oNLjjEdaY+36yfo20rZ1op+nST6s+7H3/ntSVgkMv X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: * Matteo Rizzo wrote: > On Mon, 18 Sept 2023 at 19:39, Ingo Molnar wrote: > > > > What's the split of the increase in overhead due to SLAB_VIRTUAL=y, between > > user-space execution and kernel-space execution? > > > > Same benchmark as before (compiling a kernel on a system running the patched > kernel): > > Intel Skylake: > > LABEL | COUNT | MIN | MAX | MEAN | MEDIAN | STDDEV > ---------------+-------+----------+----------+----------+----------+-------- > wall clock | | | | | | > SLAB_VIRTUAL=n | 150 | 49.700 | 51.320 | 50.449 | 50.430 | 0.29959 > SLAB_VIRTUAL=y | 150 | 50.020 | 51.660 | 50.880 | 50.880 | 0.30495 > | | +0.64% | +0.66% | +0.85% | +0.89% | +1.79% > system time | | | | | | > SLAB_VIRTUAL=n | 150 | 358.560 | 362.900 | 360.922 | 360.985 | 0.91761 > SLAB_VIRTUAL=y | 150 | 362.970 | 367.970 | 366.062 | 366.115 | 1.015 > | | +1.23% | +1.40% | +1.42% | +1.42% | +10.60% > user time | | | | | | > SLAB_VIRTUAL=n | 150 | 3110.000 | 3124.520 | 3118.143 | 3118.120 | 2.466 > SLAB_VIRTUAL=y | 150 | 3115.070 | 3127.070 | 3120.762 | 3120.925 | 2.654 > | | +0.16% | +0.08% | +0.08% | +0.09% | +7.63% These Skylake figures are a bit counter-intuitive: how does an increase of only +0.08% user-time - which dominates 89.5% of execution, combined with a +1.42% increase in system time that consumes only 10.5% of CPU capacity, result in a +0.85% increase in wall-clock time? There might be hidden factors at work in the DMA space, as Linus suggested? Or perhaps wall-clock time is dominated by the single-threaded final link time of the kernel, which phase might be disproportionately hurt by these changes? (Stddev seems low enough for this not to be a measurement artifact.) The AMD Milan figures are more intuitive: > AMD Milan: > > LABEL | COUNT | MIN | MAX | MEAN | MEDIAN | STDDEV > ---------------+-------+----------+----------+----------+----------+-------- > wall clock | | | | | | > SLAB_VIRTUAL=n | 150 | 25.480 | 26.550 | 26.065 | 26.055 | 0.23495 > SLAB_VIRTUAL=y | 150 | 25.820 | 27.080 | 26.531 | 26.540 | 0.25974 > | | +1.33% | +2.00% | +1.79% | +1.86% | +10.55% > system time | | | | | | > SLAB_VIRTUAL=n | 150 | 478.530 | 540.420 | 520.803 | 521.485 | 9.166 > SLAB_VIRTUAL=y | 150 | 530.520 | 572.460 | 552.825 | 552.985 | 7.161 > | | +10.86% | +5.93% | +6.15% | +6.04% | -21.88% > user time | | | | | | > SLAB_VIRTUAL=n | 150 | 2373.540 | 2403.800 | 2386.343 | 2385.840 | 5.325 > SLAB_VIRTUAL=y | 150 | 2388.690 | 2426.290 | 2408.325 | 2408.895 | 6.667 > | | +0.64% | +0.94% | +0.92% | +0.97% | +25.20% > > > I'm not exactly sure why user time increases by almost 1% on Milan, it > could be TLB contention. The other worrying aspect is the increase of +6.15% of system time ... which is roughly in line with what we'd expect from a +1.79% increase in wall-clock time. Thanks, Ingo