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 3272FC46CA1 for ; Mon, 18 Sep 2023 08:54:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8128D6B02B9; Mon, 18 Sep 2023 04:54:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C11C6B02BB; Mon, 18 Sep 2023 04:54:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6887F6B02BC; Mon, 18 Sep 2023 04:54:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 596D36B02B9 for ; Mon, 18 Sep 2023 04:54:23 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 35382C0C8A for ; Mon, 18 Sep 2023 08:54:23 +0000 (UTC) X-FDA: 81249106806.23.3FE3B0E Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) by imf25.hostedemail.com (Postfix) with ESMTP id 80E26A001E for ; Mon, 18 Sep 2023 08:54:21 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qDD8Pd7B; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of matteorizzo@google.com designates 209.85.219.47 as permitted sender) smtp.mailfrom=matteorizzo@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695027261; a=rsa-sha256; cv=none; b=3OQCBiN4zLghSmeBFzT33W88lltGguC7bUJzFYQfUBmJSopbfUvW6lwL+rPg/YDdWVFWX0 N6L8FkJEYRoH47B2Pnrwhf8VhBBKe8nGzghy8yGe/vWtGLmcUYhLWvVROjvD8oBTXZ2YTr utTVqMVdr7onPNeWoJOEBEH/n+9D/7w= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qDD8Pd7B; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of matteorizzo@google.com designates 209.85.219.47 as permitted sender) smtp.mailfrom=matteorizzo@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695027261; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ClIL0dCrkOnBpg+a8Xrgg6ALAEbCrlXjT2IySqiHtKo=; b=IjiryWxjims9EHC0naijSN3yPxaTy6scWmaO7iK+4Ply5YfZ8IW2tZBNtunolpbmfKboZQ pYjCJd0sbd85ApmpsNvVR8Gc4RXoeuck/kp2yJ76Df0Pnhj92rhTWCe/3kGivBSkMY6f2I 8HWcGRi0BfUz4gkmFdKo0y42dAlpIg4= Received: by mail-qv1-f47.google.com with SMTP id 6a1803df08f44-65637f0d10eso10516706d6.1 for ; Mon, 18 Sep 2023 01:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695027260; x=1695632060; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ClIL0dCrkOnBpg+a8Xrgg6ALAEbCrlXjT2IySqiHtKo=; b=qDD8Pd7BibejYiobaFl96DNj3mYtjOnbEUNXgZkzqVsspCqX7RBK8vvwGLsUnwaJ39 vjv3fZUPIUAjsSKmwEkCkBVTiht3W5qRkSGHdVrmeYjhaTg5+12/gxVua/7XRI7khJRo 4XwSgKb/N6d+vVKmRrZn6jSo9LP6LZCyWKydsyJVRYH3/8y2+jafZnCm3LR6gYtwoHTT UCg1wCzJcmjVVJZCC7wvdffUeY9VmKtBz77AQMjdTxRxugqbW7Yk2Jdxrq2+7VaA+bPA eb6GEIVn+3DAxVtHdtN/8xvcrypC/dipspbQzcAeeWOaiKEymsAZ5JWnLURD4xo+1APU l1/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695027260; x=1695632060; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ClIL0dCrkOnBpg+a8Xrgg6ALAEbCrlXjT2IySqiHtKo=; b=irnWSR+q0s/igKS41ba8wNq4eH0UDM3G+tLYDrkKNmMncpexgnQ+w9Jw114I4YPGFe k6iE6cMjEPqIUKeYS8ktNDD+hYZbh3DZJoC0myKyr7dc138W9HYgaYiNkxpZGej8EGET QjJyIOiOL/F49H+rt5+UCbhfUGCuJd7EVjOotCZF1/0Qd+/dkv3K7/2VLnO6HlOkbcb3 tgaH7BCnrsrJSZFJQsUrhOhquRxAxnvUkntAPYyG0DDNR9U0m6t8/hhFKajYDf/NQSN0 uFd/dLrKYkkOQTIUyGBhk2Our/cHT58zAMLlaLuYTCXKEZP3vnR9IeeEmhKvNifr/qE7 V3Eg== X-Gm-Message-State: AOJu0YywglvH+TjVjmzTfDEaIbkEpzzh2jKfiYrXXS+guvkX6ySYLbn8 /1QGYmbI+qjIkuz3jegMEY99CMI0XyWvkrd/TSB7Dg== X-Google-Smtp-Source: AGHT+IFYgHG0dZf5nqkpv4qVu0ChzNBIdAhruIWmcSZxRpa53s1lF8WlI4xTjt862E295HdVdB8Wq01IovaBffAM0m0= X-Received: by 2002:a0c:8f1a:0:b0:653:589b:ac47 with SMTP id z26-20020a0c8f1a000000b00653589bac47mr10654295qvd.18.1695027260535; Mon, 18 Sep 2023 01:54:20 -0700 (PDT) MIME-Version: 1.0 References: <20230915105933.495735-1-matteorizzo@google.com> <20230915105933.495735-11-matteorizzo@google.com> <202309151410.E65B8300F@keescook> <64e62982-6d0e-f742-be5c-15390d8e7c2b@intel.com> In-Reply-To: <64e62982-6d0e-f742-be5c-15390d8e7c2b@intel.com> From: Matteo Rizzo Date: Mon, 18 Sep 2023 10:54:07 +0200 Message-ID: Subject: Re: [RFC PATCH 10/14] x86: Create virtual memory region for SLUB To: Dave Hansen Cc: Kees Cook , cl@linux.com, 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, 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, ardb@google.com Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 80E26A001E X-Stat-Signature: kqwztbwr4pyhi9nqj7k3czqrmohxaz49 X-HE-Tag: 1695027261-747832 X-HE-Meta: U2FsdGVkX1+DkKIhA7e2xiIcJ5q6MC92l0Dq8r6IlOyhE4ZitG6pFwBx8ugOrpO3+45ktBJS0M41J7zQ/UDkUxf8tASyE7KdCM6MBgYI2W0pWjIKKWtG9LvB5bUmQYYD7ovv2suYI1xv3QXCpupt1D6OmVXCAAJjWmlXFZBVwVuv52tPJwaSsqxlp8vv1JhBkNCmg71ROnXCFReleMYAteOisrXYiRiyiJ/6VMskcKnOJucJU4I3QxxcYYND8y406L94hA+hMkaItxs/X/XzSK87KydGeQKllweeAMLDMnxsXhgGplEv0+I8EY5N2CBenHVhAtrmr4da7/FrEzbAiSG1ydmjk4hanJlJ9U22Oq/HB7FtsPdZpCjBLojEI/CMmJI1g67BI8W9r22Rhu0fFoybUN/kUjyO9MC2lylB9SbQ9ieXk0XM+n5qkgVdU+e/uGego/4+4Hg4rbO1iW3/bRrTuHOGfUj9zUtBceJQesKlCj7uJJi30uWoBs673yM/MIZtQF6p94sTFtxC4qNpl6T82WqhQwvHFvscfTJSzntLKqZypnU/i+3FdfzP0U5jQf+/BFFSU9qJMN0jBP+OBo/qMDkpR2EBs762TCtgb4Ilj1LN7bLyPsJqy/U48JmObzyRSVY2etdqQEZSaHDGZA2ts57eb2urzLhDj0GxBOOOFf0y0JBFzSjRijmSLN8u9ZOs5qyd5hB9UA5dDtgtMn2mm9vafUw6Z0pBqTluT2oMI10z133kWWPaAINAFCOTyhj0GJDDxq+X9Vrj2EVlE0GH3Ul0Jut1w7KFnu+XRsrMV3s67Re4+w32xDIqSycwlDpLxoOLYwqurbmCnPdMu3kg5Q2qhhzldWdG+71506q7d775krRqBjcgMZNLwsKXKdtaHBqhLiVYm9ef06mr2hdV0RFnNe5sBFTwj3YzvXgLRKcvJCFouKKlGtZAgdIQIz5QZZvjjh1jzNJmDMp 6gQKowv8 Hh9524i+BrrgJHnd3LU6P5M3s+eGVBFV+XmA+Cf2WgGps8bt1eBoooB42a99AntL4osBqEB7L00VTiizivONz9aSbFO7H/SM9jnMU0r2Pdf/uDRic4bhXEY/YSTtnIrAm7W8/ymHhYYcaP3GiCUTsG4qgemDtICyriO4tyFlygkvHk/aRrNaiRXdYS4zGxdJeSDekFXgLV205T+uFaIGhSxbHUXjtsTl0WkpAvlXam7u1HscWEBVW/CDaKWgJLg328bSxVAm0s8vjn7CwWbHTyZhucrlnmtQ5Mlktd3Ge9H6xbLGbfNHehhRtfMcESDBx89hx X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 15 Sept 2023 at 23:50, Dave Hansen wrote: > > I have the feeling folks just grabbed the first big-ish chunk they saw > free in the memory map and stole that one. Not a horrible approach, > mind you, but I have the feeling it didn't go through the most rigorous > sizing procedure. :) > > My laptop memory is ~6% consumed by slab, 90% of which is reclaimable. > If a 64TB system had the same ratio, it would bump into this 512GB > limit. But it _should_ just reclaim thing earlier rather than falling over. > > That said, we still have gobs of actual vmalloc() space. It's ~30TiB in > size and I'm not aware of anyone consuming anywhere near that much. If > the 512GB fills up somehow, there are other places to steal the space. > > One minor concern is that the virtual area is the same size on 4 and > 5-level paging systems. It might be a good idea to pick one of the > holes that actually gets bigger on 5-level systems. One of the other ideas that we had was to use the KASAN shadow memory instead of a dedicated area. As far as I know the KASAN region is not used by anything else when KASAN is disabled, and I don't think it makes sense to have both KASAN and SLAB_VIRTUAL enabled at the same time (see the patch which introduces the Kconfig option for why). The KASAN region is 16 TiB on 4-level systems and 8 PiB on 5-level, in both cases 1/16th the size of the address space. Could that work? -- Matteo