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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6771CE79AC for ; Wed, 20 Sep 2023 08:50:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233873AbjITIuD (ORCPT ); Wed, 20 Sep 2023 04:50:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233853AbjITIt7 (ORCPT ); Wed, 20 Sep 2023 04:49:59 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35D7BDC; Wed, 20 Sep 2023 01:49:52 -0700 (PDT) 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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/