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 7A1F5D1814C for ; Tue, 15 Oct 2024 03:04:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 837F26B00A5; Mon, 14 Oct 2024 23:04:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C1316B00A6; Mon, 14 Oct 2024 23:04:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 613856B00A9; Mon, 14 Oct 2024 23:04:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3A1E96B00A5 for ; Mon, 14 Oct 2024 23:04:37 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id EE983C08E2 for ; Tue, 15 Oct 2024 03:04:27 +0000 (UTC) X-FDA: 82674343584.22.911C8AF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf18.hostedemail.com (Postfix) with ESMTP id EC4501C0004 for ; Tue, 15 Oct 2024 03:04:31 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="Him/c0js"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf18.hostedemail.com: domain of piliu@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=piliu@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728961428; a=rsa-sha256; cv=none; b=QXuUK6ktpvOEv3pxWAXTh5go98kFUr2ZbZOJrwHcD3oQvF+vaOiKuzAvnHiX8g2AUP8oil s0xGG3Y81LlmTtUny+V69psB1N/+/pLKn83+EHbcSNy9nSLmtim5MyEMaijRTGCDbzcpC1 U/K5r/ZMffdHDMVpP1NFeNvDi/dDvsM= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="Him/c0js"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf18.hostedemail.com: domain of piliu@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=piliu@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728961428; 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=2LILJl12FRTprkZPDsnRty3i0K05AFLZzsWu9wwpXxI=; b=SoFMEh2o1VSrcDxCorVjTCyGkfEIkbV4wdSN+cvSfTtIoFE9WL6sG0d+9SY9m3h35AxYbG /y4TiAJiL/eEp05/HzEIzYRsQkPf+E66C0QOZ1m1AL6up/cMEa3p8smgvU1LPgDk5plGLQ L2MUfsOdL6M1AOzBZolUgQDm7T6nP4I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1728961474; h=from:from: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; bh=2LILJl12FRTprkZPDsnRty3i0K05AFLZzsWu9wwpXxI=; b=Him/c0jsL8CUmV1MJxP6pba9WywmnC17cRbgZob/DKRUjJLioRs1rzGByjes37SgyCEBo4 yHLjTcTjjVq0SoPOEdlK+EpG+DPEt5Za1V3BgUvO6szv3I6TmA1BUyqukJROjRlUrqgH3C X+NCdBRjxhPecXkXpzf5y3T3Keq8LAY= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-103-XfbZbn1LMyqm86LamFiUfA-1; Mon, 14 Oct 2024 23:04:33 -0400 X-MC-Unique: XfbZbn1LMyqm86LamFiUfA-1 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-6cbe4cb4252so103816246d6.2 for ; Mon, 14 Oct 2024 20:04:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728961472; x=1729566272; h=content-transfer-encoding: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=2LILJl12FRTprkZPDsnRty3i0K05AFLZzsWu9wwpXxI=; b=UPpdfuB3eZ83xPmDt8X8W7QTfNX76+jupAAXGVO0KFpp7KIDUVd27KJR63zxbHLOjB 4zLDbiGfyRVM27ghlo6s7JZaV+WrIitdXXKM8IIUchCyfMYjjvUVCupSvtlYY67locOz IyLxMsSvsOXEdSePbosXcXUQ+9zOwcueP1O37qIdujgBnTWqygsbfQQDsUq5TM/dhBdW 1K63507zluKQ7DJmfMao/j3cj3P1NOo3lwMZdVx3muRrJIZ1ewOFybI1VHpp7BUN33rw qhaUZC9tRel3763md6ZoChPAJawGpTfP03Omtgoxs9mrISa2LErabxYdWLrNcnC2bN0O Ih3A== X-Forwarded-Encrypted: i=1; AJvYcCWfLkW1Gx/aNHrlhW0wwd/dYbRmezuw4ipi+C78/NVesghU/6yvFLNiejBIu9MuCkjdjPC70ti1Kg==@kvack.org X-Gm-Message-State: AOJu0YzCVZCkJ/rc5DlH9oaOvEnHMKG2MN9mlOxZ3mO18HS6ALVGFywS 2AGhqtzQhujDk/SQH98qGT5DgMKwGjRtMmYtmbcpidXTrdSNy0ctmWi3+w82VyqqFjEeX06yt3C 4OdVv5F+qYTNNKs2X2886D0WDiPj549a5CfGdk0C0YfEpBXPYRmuPFkhZTcma6WJWOza4t/TseL fPJpG2yJEiRLF6i4fLsGCugnE= X-Received: by 2002:a05:6214:5347:b0:6cb:e9eb:1b24 with SMTP id 6a1803df08f44-6cbeff63948mr208010726d6.24.1728961472415; Mon, 14 Oct 2024 20:04:32 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGp3T4Yepy5h5DQueUeaIl2hWfHF7EpApBAxl9jBnWIq5Z+upYe1XYSqd8+UMzLGOwXgyDg2kobb+ggSdFvo7w= X-Received: by 2002:a05:6214:5347:b0:6cb:e9eb:1b24 with SMTP id 6a1803df08f44-6cbeff63948mr208010076d6.24.1728961472016; Mon, 14 Oct 2024 20:04:32 -0700 (PDT) MIME-Version: 1.0 References: <20241014105514.3206191-1-ryan.roberts@arm.com> <20241014105912.3207374-1-ryan.roberts@arm.com> <9b7e4f65-a171-4574-bd53-580e79527fbc@arm.com> In-Reply-To: <9b7e4f65-a171-4574-bd53-580e79527fbc@arm.com> From: Pingfan Liu Date: Tue, 15 Oct 2024 11:04:21 +0800 Message-ID: Subject: Re: [RFC PATCH v1 01/57] mm: Add macros ahead of supporting boot-time page size selection To: Ryan Roberts Cc: "David S. Miller" , "James E.J. Bottomley" , Andreas Larsson , Andrew Morton , Anshuman Khandual , Anton Ivanov , Ard Biesheuvel , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Chris Zankel , Dave Hansen , David Hildenbrand , Dinh Nguyen , Geert Uytterhoeven , Greg Marsden , Helge Deller , Huacai Chen , Ingo Molnar , Ivan Ivanov , Johannes Berg , John Paul Adrian Glaubitz , Jonas Bonn , Kalesh Singh , Marc Zyngier , Mark Rutland , Matthias Brugger , Max Filippov , Miroslav Benes , Rich Felker , Richard Weinberger , Stafford Horne , Stefan Kristiansson , Thomas Bogendoerfer , Thomas Gleixner , Will Deacon , Yoshinori Sato , x86@kernel.org, linux-alpha@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-openrisc@vger.kernel.org, linux-parisc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-um@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev, sparclinux@vger.kernel.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: EC4501C0004 X-Rspamd-Server: rspam01 X-Stat-Signature: tc9fgyyq1zrxmsw4d89nm7aoued5m8wr X-HE-Tag: 1728961471-757389 X-HE-Meta: U2FsdGVkX1/FCX1/8HxCizY++xPG0OrRlB4X1XxYwJWYL4vTFcHa6bBOqJoMulIIc0yr1M8Kph7ytfp8c3LFicD06zxUAnxykoGmt9mQJm1coXaHryMhMT0RceZUUAw5EVyj3XD2Gpvt2m80lwQq+5M5EdmAZsaiSkQbdvehpkky92P8v8RJqbZf+9INrF9Ov/8Si91gY9XiZBWODQEfYv10e4Yuj679CvQwc8c+eQGd/BtkI0sAaJusPtjdXGNo7KaxhBqRj1tVkv4+xD3QzB58vtlQqp9KkDb3yQZ7Sc+/sdYZRY401hZSjuweixluO82KijYAN1ccc3TEiWGGLF2lBraVYPzjNTN+PXXP/iu9zMu1tUjFVIGxwHK464BPgwyKIHwTxGU5eUJFa1MZazZu6wvKZ1DcRWnuDsxSqyJBOZ7ka658koBgMX1WhLuR9KJijhh9Qxm8FGE7MMtJn527CCrYJauTpxNm6U+mx9whdvVd6IW/LkgC5USHBfYbjFBPay4wLlo6Zvca7kujOaNwzLC/4e0ZYwtE2X50BwZg/FyNwK3+R60/PuhDw8imKuaH7QfwevuL1tvld4KRsDX7NguXF9xZAACV2UoOfj6cJLfjsejDgQUo83O+p/rS3ueykxAT0pO71FwWBcIaazyUUaw749qe0ZSKhh2064V5KGcECcFmddXsOwdpPCaYr69drTCA5aL0KvO7s9DwRJJw+PV8q1zVtIlyFfpSgVn4PAs3QiBOXmUUO5Q+GxRg3S0mpIcWZIOLM6VVWX+34opZ+hRLjR9KWXPCu3qvCE4Vxesa+mcrhgA7SPmoTtkvvzgDyk6KwerbCPZP13c/e0vEllXrRaDCtXQJOkhylt1m3O3SnabcK1EApUmA40AIDdkcI7noJ9Sa3OR/Y3xe6f04pBEGpCshur9/NsXmORgO2dVd1+SKuMaBp+1Kr1gdGGCq305qs0r3FmLlOZh +2P1eH9z F1Orhfhd7vk74v0CahYWY91dMjnhRssVGRJPWk8wDwxe/Wh7IOHlHc+QWbYCdTDaP+RJq49rlUiD5ZAAbquIGhQ5Br3t5qJCWEkdGIMBTpE3fBk3WAY1iL4Q6Or6aSDNSabyMCUO7H8m0wOGDfzZYloSZsfN87D8e7umMwZX7jrQ4C91CRwfrESp1snsN8idEKItgi6ie6ZoNPsfpcBxwGwMATMlDuBfTKSzC9NdQotO6OHBAq15KRWugg8WPWoMgB/vAoS+xh3Log8M4JnpXEweFf2h/aaFEmq6ER9IS9hEP43oZpm8zYQNzBw== 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: List-Subscribe: List-Unsubscribe: On Mon, Oct 14, 2024 at 10:07=E2=80=AFPM Ryan Roberts wrote: > > On 14/10/2024 14:54, Pingfan Liu wrote: > > Hello Ryan, > > > > On Mon, Oct 14, 2024 at 11:58:08AM +0100, Ryan Roberts wrote: > >> arm64 can support multiple base page sizes. Instead of selecting a pag= e > >> size at compile time, as is done today, we will make it possible to > >> select the desired page size on the command line. > >> > >> In this case PAGE_SHIFT and it's derivatives, PAGE_SIZE and PAGE_MASK > >> (as well as a number of other macros related to or derived from > >> PAGE_SHIFT, but I'm not worrying about those yet), are no longer > >> compile-time constants. So the code base needs to cope with that. > >> > >> As a first step, introduce MIN and MAX variants of these macros, which > >> express the range of possible page sizes. These are always compile-tim= e > >> constants and can be used in many places where PAGE_[SHIFT|SIZE|MASK] > >> were previously used where a compile-time constant is required. > >> (Subsequent patches will do that conversion work). When the arch/build > >> doesn't support boot-time page size selection, the MIN and MAX variant= s > >> are equal and everything resolves as it did previously. > >> > > > > MIN and MAX appear to construct a boundary, but it may be not enough. > > Please see the following comment inline. > > > >> Additionally, introduce DEFINE_GLOBAL_PAGE_SIZE_VAR[_CONST]() which wr= ap > >> global variable defintions so that for boot-time page size selection > >> builds, the variable being wrapped is initialized at boot-time, instea= d > >> of compile-time. This is done by defining a function to do the > >> assignment, which has the "constructor" attribute. Constructor is > >> preferred over initcall, because when compiling a module, the module i= s > >> limited to a single initcall but constructors are unlimited. For > >> built-in code, constructors are now called earlier to guarrantee that > >> the variables are initialized by the time they are used. Any arch that > >> wants to enable boot-time page size selection will need to select > >> CONFIG_CONSTRUCTORS. > >> > >> These new macros need to be available anywhere PAGE_SHIFT and friends > >> are available. Those are defined via asm/page.h (although some arches > >> have a sub-include that defines them). Unfortunately there is no > >> reliable asm-generic header we can easily piggy-back on, so let's defi= ne > >> a new one, pgtable-geometry.h, which we include near where each arch > >> defines PAGE_SHIFT. Ugh. > >> > >> ------- > >> > >> Most of the problems that need to be solved over the next few patches > >> fall into these broad categories, which are all solved with the help o= f > >> these new macros: > >> > >> 1. Assignment of values derived from PAGE_SIZE in global variables > >> > >> For boot-time page size builds, we must defer the initialization of > >> these variables until boot-time, when the page size is known. See > >> DEFINE_GLOBAL_PAGE_SIZE_VAR[_CONST]() as described above. > >> > >> 2. Define static storage in units related to PAGE_SIZE > >> > >> This static storage will be defined according to PAGE_SIZE_MAX. > >> > >> 3. Define size of struct so that it is related to PAGE_SIZE > >> > >> The struct often contains an array that is sized to fill the page. I= n > >> this case, use a flexible array with dynamic allocation. In other > >> cases, the struct fits exactly over a page, which is a header (e.g. > >> swap file header). In this case, remove the padding, and manually > >> determine the struct pointer within the page. > >> > > > > About two years ago, I tried to do similar thing in your series, but ra= n > > into problem at this point, or maybe not exactly as the point you list > > here. I consider this as the most challenged part. > > > > The scenario is > > struct X { > > a[size_a]; > > b[size_b]; > > c; > > }; > > > > Where size_a =3D f(PAGE_SHIFT), size_b=3Dg(PAGE_SHIFT). One of f() and = g() > > is proportional to PAGE_SHIFT, the other is inversely proportional. > > > > How can you fix the reference of X.a and X.b? > > If you need to allocate static memory, then in this scenario, assuming f(= ) is > proportional and g() is inversely-proportional, then I guess you need > size_a=3Df(PAGE_SIZE_MAX) and size_b=3Dg(PAGE_SIZE_MIN). Or if you can al= locate the My point is that such stuff can not be handled by scripts automatically and needs manual intervention. > memory dynamically, then make a and b pointers to dynamically allocated b= uffers. > This seems a better way out. > Is there a specific place in the source where this pattern is used today?= It > might be easier to discuss in the context of the code if so. > No such code at hand. Just throw out the potential issue and be curious about it which frustrates me. I hope people can reach an agreement on it and turn this useful series into reality. Thanks, Pingfan