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 41CFACE79AD for ; Wed, 20 Sep 2023 08:49:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CE0526B0133; Wed, 20 Sep 2023 04:49:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C8E966B0134; Wed, 20 Sep 2023 04:49:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B7D496B0135; Wed, 20 Sep 2023 04:49:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A980B6B0133 for ; Wed, 20 Sep 2023 04:49:55 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 71C3F1C9B28 for ; Wed, 20 Sep 2023 08:49:55 +0000 (UTC) X-FDA: 81256353150.11.A78DAC2 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf30.hostedemail.com (Postfix) with ESMTP id 657E280012 for ; Wed, 20 Sep 2023 08:49:53 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=LHVFHkXQ; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=t468LGTe; spf=pass (imf30.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695199793; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=HX5pPg3EIgB5tnraIeoBZTHS0SCTNA9W4l/mVV5w2no=; b=SKb30NTbjApvWGxyYDUU7AD4eHh/6B7LnoVRHefWCh/rZcQJxZnfEFHWVGC1QbFUWvZe2m AiBDGtzB2eV2x6uCk4m0w98oeX27xEltrXF7Fdre0tGZsE0XUzSC6j/XN0W7B5fkpVw6oh uDkIXWa0Q59slKDKXpyIfOgWsOnyi2Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695199793; a=rsa-sha256; cv=none; b=gXhwcU2tPDoYMaGr6wYZ+0hgrDrweylqaUGMwtFLSpWbLVWMfT0dhyLIX7JQ1jBUmLvMmS HzGBqa1c+LgyXpk7WaX5kbvQR2jZH+EEGPUchVTVjDUy1rk7370qndosu5LdjinR1lmMy+ dX6Wtdc4xYZQfWNwC+xyw7y7JGvARGw= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=LHVFHkXQ; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=t468LGTe; spf=pass (imf30.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 419801FE0A; Wed, 20 Sep 2023 08:49:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1695199791; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HX5pPg3EIgB5tnraIeoBZTHS0SCTNA9W4l/mVV5w2no=; b=LHVFHkXQ55/j0xSp+zPQLMOZ3OlKzq82cbMsy3h/grCDs2mXdcylirJP/DxG52b++qCDfG fI5JcmZV4PWWa+4eARqDxPaBl37nm9P76+W/o166WPruHNXqO1Ah+UKqIJ4Ka41VbbsgLl oq7pJ0qfkb0s2fwF4g5ljtQA0ePPK4s= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1695199791; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HX5pPg3EIgB5tnraIeoBZTHS0SCTNA9W4l/mVV5w2no=; b=t468LGTetz8kGMyaGPGD279qVaYSRjdOcZU+YgTSUTf4EincTWPBRpxxEq7xwQqDQiYU2z BdCfOFI9FPXSBZCw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id CF004132C7; Wed, 20 Sep 2023 08:49:50 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 4e28MS6yCmXeYAAAMHmgww (envelope-from ); Wed, 20 Sep 2023 08:49:50 +0000 Message-ID: <40bc28e5-c971-055f-eff4-b9d67fe768cc@suse.cz> Date: Wed, 20 Sep 2023 10:49:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [RFC PATCH 00/14] Prevent cross-cache attacks in the SLUB allocator Content-Language: en-US To: Matteo Rizzo , "Lameter, Christopher" Cc: Dave Hansen , penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, 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, Mike Rapoport References: <20230915105933.495735-1-matteorizzo@google.com> <7a4f5128-28fd-3c5f-34c2-1c34f4448174@intel.com> <1d7573c0-ebbc-6ed2-f152-1045eb0542f9@os.amperecomputing.com> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 657E280012 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 3d1zu6pwnb9nknpb37nga5tyf8setb55 X-HE-Tag: 1695199793-10267 X-HE-Meta: U2FsdGVkX1/FC2aAQsoEwIArKCM9l87fagwwX4YPIPyXLh9mW+sLjaPJR6o15ytb+XTWZFWXU89qEh/H9yZMuHvb1k9fIHr8sAFJMZtrrDNg6TdpkI5IsG15vJ1P8mZYhZSilGPnDBVYVejQPe4NQXqJ5GNUaa9kjHZP/QP8JL2hfOHLa9YHiUm2svwMqebFFwYr/nVckb7Hvy/m91cdRsKIZd/2S5byrOT/qXIOei/ikFDcMB0uzdhgLn0HsJ3TdEcIr+3B4R92yRJlt16SUmDJCV8nqikjTHFgPKy4Vy1vUZlYgiUe4EEc9KMy6j+I06BF9i43bk4chgo912UX6B/9gVLDES+XhrkgJavAsI7dKH20/70UuOYD2hjlWb33pHGQoE0LUQNXRBFbABz4w5Y72qdnAcIWDTZBZr9MXuRPPnDXpoE2xaIvh86x5tcYaM4C+RC2aBL7w27gypRzaQol0IkmPX8wmYYKC4PX6T5fNQzaRlcxeBnhqn9VzLoQMQ7OaPOv5niFD9h7NqMZEugH9A14W/B1p7Ks6FMRzjQeEEg8FgRPw2lr7jZ1GxnfBMeREwirIoxV8/WqEn4Ap1iTDaPhXBtfMozVUsiGgDmex6GsHvv8soWjknq5ZcP0RKYYkxAaYY533r9kmUsCAWtL5/7cEZSHRPCRqI6W7mZJzHHf+oeE7NYNpAw3Lv22OuFLnpsdqJk0ql6iMjKd+HH+UIxRdkH/FNpC1Um+3+pbP5Mn8CH8AaGMuEf/jzFse49Lol3tC6wAPaaktiXfLl+BlUhuewaKW6//AHTD5KN5+49kxlMOcVswIBw33C/QKgq6slOPnKSzIyFr5MwBsTejO7Q5WgBZ9nCTq6sW/c5ALNIkU9cNf8jLvN2tHCQYclKsjuLClOWoagcb/JwFaqb2Ld55bBZj2jLMnrBzKHJ3SWocwbOJYxMrwPr54IdoEckG/iqRz5+N+ec/mJG KyXimisg xuawhGSsz0vqY/ICxEWjpX6qOQRioBi5p3YWDAzJ7o7QCkxeFj+YJWqEgLPGfWCQWu7LD5WIhKyqZokWvYnw/UBAXzGM3vNSiWu3aIH6r4WGkJ4mHMeBp7T8rfOiiqLvCn+bi8d/EHNIhJXzOASksXt6mv+vC2dl+scpBBnJ1oz8/q2/RtaE7hAo04lZd+AUSiasd74JefsAVelyou1BRpkyfwKzPna3Rv7MkPICfUFLzRkjY+Bh9skIlgOME0XvlKvxD+8BTUKP+UcZMu1r0/pZe3YbYWNcQgJy0wkQAgK8ZUUUia3xzB+kRX86voqzP5nBuvr9h9hSyhSQ= 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: On 9/18/23 14:08, Matteo Rizzo wrote: > On Fri, 15 Sept 2023 at 18:30, Lameter, Christopher >> Problems: >> >> - Overhead due to more TLB lookups >> >> - Larger amounts of TLBs are used for the OS. Currently we are trying to >> use the maximum mappable TLBs to reduce their numbers. This presumably >> means using 4K TLBs for all slab access. > > Yes, we are using 4K pages for the slab mappings which is going to increase > TLB pressure. I also tried writing a version of the patch that uses 2M > pages which had slightly better performance, but that had its own problems. > For example most slabs are much smaller than 2M, so we would need to create > and map multiple slabs at once and we wouldn't be able to release the > physical memory until all slabs in the 2M page are unused which increases > fragmentation. At last LSF/MM [1] we basically discarded direct map fragmentation avoidance as solving something that turns out to be insignificant, with the exception of kernel code. As kernel code is unlikely to be allocated from kmem caches due to W^X, we can hopefully assume it's also insignificant for the virtual slab area. [1] https://lwn.net/Articles/931406/