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 8611FC38142 for ; Tue, 31 Jan 2023 15:17:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1DEB56B0075; Tue, 31 Jan 2023 10:17:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 18E686B0078; Tue, 31 Jan 2023 10:17:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 054E36B007B; Tue, 31 Jan 2023 10:17:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E658E6B0075 for ; Tue, 31 Jan 2023 10:17:57 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C1A0B160C77 for ; Tue, 31 Jan 2023 15:17:57 +0000 (UTC) X-FDA: 80415449394.10.A87B759 Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com [209.85.221.180]) by imf27.hostedemail.com (Postfix) with ESMTP id DE7C24001F for ; Tue, 31 Jan 2023 15:17:55 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="e1IRDig/"; spf=pass (imf27.hostedemail.com: domain of glider@google.com designates 209.85.221.180 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675178275; a=rsa-sha256; cv=none; b=zU8iZYOmgGRQ4PKZvoD6xmM9805PyPf7PALR7kHIuxuXpkcFEmYXix6K7FGb1ylocgqWlN xiBpM0G7b4t5Wg81oOkuabUeXH6HMF7NIfRRocZEISLZ5YtJXXkUcgVKC4qcbqAxP+a5f7 fRxwmDoD0v5oSLNWZL84Af69TfWq28s= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="e1IRDig/"; spf=pass (imf27.hostedemail.com: domain of glider@google.com designates 209.85.221.180 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675178275; 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=HO4BAIAwhR/8dHxNa4V65cuTt/guC5rFbEzUi17Mn2w=; b=3sEWBNg5mA7CDPGSd9RTGdk+4rmxD6ca2jiiF2aI0rKVGOmsWwGQuZS9eOWXOtA2xweN1C psV4f+9Uv4w2C1OyF9g1RNDKG0215vDtIUs4jnR434pustNeCJWlZOequ7KW51kP5/SOGO Z2KcvhkFxmhRRGoNCUfL1dsLl+nG7/s= Received: by mail-vk1-f180.google.com with SMTP id b81so7548618vkf.1 for ; Tue, 31 Jan 2023 07:17:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HO4BAIAwhR/8dHxNa4V65cuTt/guC5rFbEzUi17Mn2w=; b=e1IRDig/BS4/25E0+MVfobgLvc/UM4UNqF6kD8IGE0/UEhC3wzw/drzzheebsPSLgI BjZYuVg7p4221/Jx9PsX/4ghN+bTo7krsS/k7SxBwAhmq9i7ZrLeNb3rWaGS1GlXnZcZ mQTPEBYHDv8tiEz1ow9bo59/5JhlRt7V9VU3iRMi0a8zlaj1pdcxvvvXCq1GRI0YPHoA C6FjpAP+Fcy9cOofoWoWrLyzEmerFPqeT9pp5vHQthr6b/rMUScjD257bKPcXNnhKLsG 1NOC9/gI20SYcARxjWaW+hnwAhFoHHimi2SVEdBSUsjMh5PPl1f5Wi0NQ3vUir5e7CtB cX9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=HO4BAIAwhR/8dHxNa4V65cuTt/guC5rFbEzUi17Mn2w=; b=UCGNDVFMo298IPl8xxEpvaRA6kJwcDJNU8kvAcnOwNVuQRN97lU2bHPuPPnziCIF5n e9iQH3YT1X74JCVJPi9WTYHqkZ22vO2GKJkA4+9UCPxy2hrppZCBcf2Cky4H713oLCgu +p0sRot8QNYfvscDMjFXD5B391kbP3N6uptJrKV5dpWlLuHs5s0l5Cmnr0ucHNr+PFs+ moXHGNuC8UCXK0pnjAtJHHo7Lx5RUtbDQQVqF4NN/JItJo0WcsD+VhOBC4Y7RpejVupw /zUfCw3rOHq3UkLTxE59rLDrdit3Mid2NPLqOy9tMjBeS/e1WnS5Cd/6R6zkt+LDydS1 JHbA== X-Gm-Message-State: AO0yUKXHOE6yvKr0l3TwJ2Wq/a7mwdxVG/ZE/ntjzUx3eAHuhzxq1R/8 5smDVNav4drlJP9xtyqOJ7gEJtLMmVpb8uEmw6jmaw== X-Google-Smtp-Source: AK7set94yyrXZTv7NqDwMt5QRHdrOS7b64VoCkDah2vhsGZl+yBW/4zrsMXWM4PUmBC1tET2r43LEgEfvXfSo7lQnkI= X-Received: by 2002:a05:6122:2498:b0:3e8:a035:4860 with SMTP id by24-20020a056122249800b003e8a0354860mr2655158vkb.7.1675178274749; Tue, 31 Jan 2023 07:17:54 -0800 (PST) MIME-Version: 1.0 References: <20230130130739.563628-1-arnd@kernel.org> In-Reply-To: From: Alexander Potapenko Date: Tue, 31 Jan 2023 16:17:18 +0100 Message-ID: Subject: Re: [PATCH] mm: extend max struct page size for kmsan To: Michal Hocko Cc: Arnd Bergmann , Andrew Morton , Alexander Duyck , Pavel Tatashin , Arnd Bergmann , "Matthew Wilcox (Oracle)" , David Hildenbrand , "Liam R. Howlett" , John Hubbard , Naoya Horiguchi , Hugh Dickins , Suren Baghdasaryan , Alex Sierra , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: DE7C24001F X-Rspamd-Server: rspam01 X-Stat-Signature: 4fcfzo114pxxjq7m7wz9kbhidmkc6thm X-HE-Tag: 1675178275-476256 X-HE-Meta: U2FsdGVkX1+u3773kJjJJAAgYWNSq2HKYHWcfHDbBPEmnmCJpPKz2XWCghG0N27k/XDVsNDazHVpMHjLQHiPYp/ChX0X7vdML81fHSSutKk7M6V9ekZ+fyT8pCXFZ/Q1GIzhxk9PGxfgDF9w/OSLBWpdJdPBk/49ou5U+M6XVmcgqjOCpWJXQu+G5MF3+IpPLOMRWdyUy3WIpFDCr72mgK1trmoLUVHnLYOvPYCSHGs/Q4x76KU6+VHkwCV87+gTfXpl4yDBXDhNZYKQ0CTuEFNJMgfTv0QUPROnAe53/ihOVId7BZanzdBr57hGlxk8i+JPeRYvaG+Ye/ocXccK/gk0gijphvn6lVVQNONCHObBmmWygDAO+Lshx3DIxN6WR9VdymDCG80JzJcfSzPqUUdFaUi35eF4IB413Gjacd9CVt5TNXPJ9Zgcyr+sia9Zr7KCnxhliuwZZ8nXPhxVl+2jUjKNtGxZ6wj2LXGy1qTMZrez/MpOc/VXXnnO143x7e3YLSurAGThigkYOG2K6GgGYUnTID6RmZgMvkffJN1kSJk3PxboeaLIPKNmO1Ww8zTwycTHjQOQ4YBNQJdE/j9nS+yGE7qCcxU2mp03K/1st7rrkeibo+6fW6+4SRqYZYEY0rHfwlEpjq3iQuinUh1JiGDT/qUUFvOPc9WmuKRSXiU8qtsIks0IIYCRKQaL4ztqfNefCPXnCuZvaeq1MR3nNubbTFzHKelUlVlZPasy9Os8m+mYdEI8m8Lxf2qHic9otDEDi9VWo1+g660fmoznLME4JyMJvs6C03JdNRSs77qs57eFakDGptAp5bH2mY48S5wQ2RpBs+57dNOY51Ep5eXZSLj/f50FYnvLLs5RUjUjlti7pTdUjOBbH4lXiN3GqfglJrTovb4RK0PlOwPmHoP+eqa7LmtjZApwhE7NEwDkNQ5zUYCQkTOAUGpYFfPnaSVm2RVlED3kFov I66MqS6/ aR7vibjW7LsB9ttWwNS24MPnQLpE18XZG6TdHs5G63OwCFXfNYs5S6cthpnMfQbX+Ee+O2ZkaEqubEoUIh5I20IxFOCHXVDzB+XVMctIr3oIs9994d8XAUj2ovqZVKZk3aMzczsFYFXQmOHeS3yl4PJ7CoXQq3kDy4E+llKvrreI7dC0iI30Se3jSp2iC5Sj8SvbzMLEIABwZBmNQ1fuiiBtt4iuxaCRRq4/3UTyjTnojnGUaLbo2/sD6O/kP0wjbxNSjeUCy71taqEPuGEbTyBvm0Q1b8HFnLk30x0umtHlwogmVCIj29moq1MuchXAG6gG6VvhgRh/4JifGEdD0/lc7sg== 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 Tue, Jan 31, 2023 at 4:14 PM Michal Hocko wrote: > > On Mon 30-01-23 18:59:45, Alexander Potapenko wrote: > > On Mon, Jan 30, 2023 at 2:38 PM Michal Hocko wrote: > > > > > > On Mon 30-01-23 14:07:26, Arnd Bergmann wrote: > > > > From: Arnd Bergmann > > > > > > > > After x86 has enabled support for KMSAN, it has become possible > > > > to have larger 'struct page' than was expected when commit > > > > 5470dea49f53 ("mm: use mm_zero_struct_page from SPARC on all 64b > > > > architectures") was merged: > > > > > > > > include/linux/mm.h:156:10: warning: no case matching constant switch condition '96' > > > > switch (sizeof(struct page)) { > > > > > > > > Extend the maximum accordingly. > > > > > > > > Fixes: 5470dea49f53 ("mm: use mm_zero_struct_page from SPARC on all 64b architectures") > > > > Fixes: 4ca8cc8d1bbe ("x86: kmsan: enable KMSAN builds for x86") > > > > Signed-off-by: Arnd Bergmann > > > > > > Acked-by: Michal Hocko > > > > > > I haven't really followed KMSAN development but I would have expected > > > that it would, like other debugging tools, add its metadata to page_ext > > > rather than page directly. > > > > Thanks for the comment! > > I was considering page_ext at some point, but managed to convince > > myself it didn't suit the purpose well enough. > > > > Right now KMSAN allocates its metadata at boot time, when tearing down memblock. > > At that point only a handful of memory ranges exist, and it is pretty > > easy to carve out some unused pages for the metadata for those ranges, > > then divide the rest evenly and return 1/3 to the system, spending 2/3 > > to keep the metadata for the returned pages. > > I tried allocating the memory lazily (at page_alloc(), for example), > > and it turned out to be very tricky because of fragmentation: for an > > allocation of a given order, one needs shadow and origin allocations > > of the same order [1], and alloc_pages() simply started with ripping > > apart the biggest chunk of memory available. > > page_ext allocation happens quite early as well. There shouldn't be any > real fragmentation that early during the boot. > > > IIRC if we choose to allocate metadata via page_ext, the memory will > > be already too fragmented to easily handle it, because it will only > > happen once alloc_pages() is available. > > We also can't get rid of the shadow/origin pointers in struct page_ext > > (storing two 4K-sized arrays in that struct would defeat all the > > possible alignments), so we won't save any memory by switching to > > page_ext. > > With page_ext you would allow to compile the feature in disabled by > default and allow to boot time enable it. This makes little sense to do, because KMSAN requires heavy compile-time instrumentation to work. One cannot simply enable/disable it at boot time anyway.