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 0EBCDD3E18D for ; Mon, 21 Oct 2024 07:26:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7981A6B007B; Mon, 21 Oct 2024 03:26:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 748356B0082; Mon, 21 Oct 2024 03:26:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E8DC6B0083; Mon, 21 Oct 2024 03:26:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 415796B007B for ; Mon, 21 Oct 2024 03:26:41 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EB2791616B9 for ; Mon, 21 Oct 2024 07:26:23 +0000 (UTC) X-FDA: 82696776456.06.FC1A01B Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) by imf11.hostedemail.com (Postfix) with ESMTP id 8D34C4001A for ; Mon, 21 Oct 2024 07:26:21 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=GA57OG7E; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf11.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.178 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729495562; a=rsa-sha256; cv=none; b=loRpBk/Qe438H+xO2R1cqyqIBzj+LVxAcGvke4RcgAvD4XiPMAe6Lkm3Ard9Afkiq7nuGk +2ztQqCVi8nw9r+pO6Jer0rGroJlq8ePtYLxgPyV+AMtbEEDAacXDCisLSjvFR2RVOihig piypoftuaB/QrmNVSNNGYB5hBekdx5I= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=GA57OG7E; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf11.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.178 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729495562; 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=1iW7zHRRBIrIicRdTUgHWKYd7YrTdzT9PhDQ/2eOzio=; b=IhChy5zt1nK8c5ayev/vAWllqoRQfAFwtrRdqkVtlr61ma2cOqAdcqNQlk3n6osQSDZ2Gl sHAp1mMgANWyIhxbSIUPbaS4nwk57WveEa02wm0pAPjY7aoTSwz4JMNG9OPVaHj88yWIlE Fhonh67/tdXrmfnJpDYVXU+Gi+TYPtI= Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-2fb498a92f6so45134011fa.1 for ; Mon, 21 Oct 2024 00:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1729495597; x=1730100397; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=1iW7zHRRBIrIicRdTUgHWKYd7YrTdzT9PhDQ/2eOzio=; b=GA57OG7EqjgYxgW30fkVQFdU2WLEsn0VXeS8EM7UirSUvfPhEUYCOJ6vmcDA4H0iy0 T17SyMlliHUYTqMplV/yzQYblSQbZFULcN8r6CrjDdMxMAXLFBPZ1tTrNvS+fnmkXW9D X0Kibbfm4mqKlZVy1pNtajaq1eriKQ3RD7BCfgHnBXBjRV0ikYs1rpMqB2b5R5RdaNxA BptbWN5vfVjoIrVs+5Q6PIWsRAVswKqRY5/wkVwJf07N6gXqU9JYfP5zAECbEKUtz448 TWkyJ9jnKI4g+AJgRmeDP68w3HG5Yuk3mexUVpvv7RbbtAtuTSPA+TGI3pEE7AP+tRDE KsMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729495597; x=1730100397; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1iW7zHRRBIrIicRdTUgHWKYd7YrTdzT9PhDQ/2eOzio=; b=D0J+2smE3NBj6m/n4HA28RyMogARMTtQxXBNKLsgKIJbJ0xYol6YT8CkrlHC04Y7Yy mPexeqwGVQnd+ni0W/UMzpdnbEuQ5nz36XkwbAnTXNEp3+IVBMpja/Lzvyoii1m0D+I1 kfBsm+jfzgnJ0YoCmVl74lMV562JQX7GlcE9ekYb3t8s6r76thHnEiqdm8e133z+qn2+ 62FEOwNFE76MN+Nkmf+HU3qwblYwCdJAUoTLF6SQd2FkQXa0JL8R+EPFMCFZsA66UeyU alyVX2DaRnYbm9xPu25PP4HJyzKa47SYeKYnHzApfhXdCV5k++gKaEfree3AVzazZ2jU lP4g== X-Forwarded-Encrypted: i=1; AJvYcCXA4Hd9l0ZOmqfhyHSiZrNN0cUNp44Y9p7EdmTL7+aWOCm5VeIAz0U0ZgLWJjF5NHeyQoN828RYlQ==@kvack.org X-Gm-Message-State: AOJu0YzO/8yR8eT0V6sXMBOb8s2r4EAyPBUTDfZy0cLJMyynLC3aJZgJ KRz70hKkfvR/+la60f+GrMa+wsa7VGy0AehJLKxJPoAUN2RH98GYM9/4nwb2d0c= X-Google-Smtp-Source: AGHT+IEaIIlMaaA/c4s+FmIRsV38tfJXNw8YcF/Nn1xqhJFI0pm7wR7caance5o0xCeMZwsESMW0uw== X-Received: by 2002:a2e:d01:0:b0:2fb:5ac6:90f0 with SMTP id 38308e7fff4ca-2fb831e94b0mr37655971fa.34.1729495597083; Mon, 21 Oct 2024 00:26:37 -0700 (PDT) Received: from localhost (109-81-89-238.rct.o2.cz. [109.81.89.238]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5cb66c6b163sm1697370a12.76.2024.10.21.00.26.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Oct 2024 00:26:36 -0700 (PDT) Date: Mon, 21 Oct 2024 09:26:35 +0200 From: Michal Hocko To: Suren Baghdasaryan Cc: David Hildenbrand , John Hubbard , Yosry Ahmed , akpm@linux-foundation.org, kent.overstreet@linux.dev, corbet@lwn.net, arnd@arndb.de, mcgrof@kernel.org, rppt@kernel.org, paulmck@kernel.org, thuth@redhat.com, tglx@linutronix.de, bp@alien8.de, xiongwei.song@windriver.com, ardb@kernel.org, vbabka@suse.cz, hannes@cmpxchg.org, roman.gushchin@linux.dev, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, pasha.tatashin@soleen.com, souravpanda@google.com, keescook@chromium.org, dennis@kernel.org, yuzhao@google.com, vvvvvv@google.com, rostedt@goodmis.org, iamjoonsoo.kim@lge.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v3 5/5] alloc_tag: config to store page allocation tag refs in page flags Message-ID: References: <6a2a84f5-8474-432f-b97e-18552a9d993c@redhat.com> <9c81a8bb-18e5-4851-9925-769bf8535e46@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Stat-Signature: ueinwfpe6gp15f7kyw51bn5okmd876n9 X-Rspamd-Queue-Id: 8D34C4001A X-Rspamd-Server: rspam02 X-HE-Tag: 1729495581-320554 X-HE-Meta: U2FsdGVkX19xQtkX97gSHGewFLaNzwoMu5XBUWkWY9UpYfs6mDrbOKDPkHhueu4/6h9aHT/OxOd25/V5mgB1CqcGkUWc8Ibpt3nltXy0l7gD9yNZSOIMPIXv5aCgoMn5L6VpObLQnd4PTsd1mkEkh73u/Z+e3LM0X1k5L9AwdFGfBsfNcSBH+0Jpe7io7Dim2l+yWKhesUi/bvNgMUt+JAeKxyITQRrh9hlvx3hmXJ7vm+mxSghrCvk+FjW2Mih3DubWx7r4NXH1q0mJTI+jzOyVS13vTdYV3PDwd0cNCfuB98COmqzEPYlRf1AxOcMPnTB+RMScBA+PrFQyk5XkhbuL9FFV0nzZZFvVRsZe34rSbWqEISX7+C/mcvHw1SBu+n8A+LnTsuLh9moGDc6HaUBQIAXxDJ0pW8Y8DwP/ssDEqp0uoKw2WRYw1XFTAqlRt+hrjtiTKBu4ezGgPEwee3PKLV1rJCHmMNEzEEDCOURLSOo7rKDU/R4plQBBin/nGUseWXBQLNDwYYFrbvgk+Er2TA3UfcYRTPmHT2nSSy5JMrlZuDtmjkt4OM4jzoje52Fhcude9w13nmNIC59ePtUnop0nYrt0skhW9nOUD6WL9cF1KnCMqi0xiiVPRvXvMClmiZmscKKE/I1SoF8tN8+013TcFEdZOjgklN2Sl5qtW9V20uFwDBH/daqk5vXjb/pYQDgPoQArDaimD4GGbXmAS6M5LLE403T3KSK5mQtq11fx1RQVe2hKl8JuxWd3XvoXI+J4uXirp5EDLIHZU5nMd8z21gRpYcBSt5wx5iYcODHN7T8hyjHkaEFaft9a+PD2NPnRoQsA5MPbnRrppTIcZiNAP/5rb7cCL0VTN8aRh/bTwUpw6OXo2zqi6wZjEbzFUjNyhYzsy5aTYtlOJ3zY/pBnAyfccx5svMd39hBePlBRNVu5WzU1Pc4om0z2Frtc8MViUmqkfcFDdzJ tJ7eLyP+ xQ5njq/zqkRHDDpQbDKqrkfNk12/Wsmoc4/GKvIRGza79wna9An1kQC5zifn5qFNCRavyU203Jvf6hsnU/iB2S9h+zDwCRqW2Wlbn9Z7O2W9yt0Y/51M07lfq6Or842Pw/jWQ5ZQME9iLmKY2SQwKep8i/wL+IhAlyErPkWsp52gHGQmLdv5D0EUB2evMfAiT8n+ss6Rk5MdCDtNLK+z6CdrY8WlzT18mUri0Xll8EYBD2/QxXsZ/aqNftNGdpRl/EhXP5tEyx5ZX2dnS6PLME3le+41qxFCzoerj9Tt1ezfNP2C2YZz5R7T61LzLcZ2V2Y8b8KOUGxVoRxl/XcaaGtjpRDrqot+wIfmAzS/HdrkyFAgvZ8eHSCYF+0/5FUblCfYTW0vbpesmkJ8WuouAqXwFaNtA/cYePGZ8tng97bu7GHVBd+MGu58rclkDV+Wpx1801VKGqRCpHE3tE5m6uQX4T0zmBi8DhivZ/WGBxG8FRos= 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 Fri 18-10-24 14:57:26, Suren Baghdasaryan wrote: > On Fri, Oct 18, 2024 at 10:45 AM Suren Baghdasaryan wrote: > > > > On Fri, Oct 18, 2024 at 10:08 AM Michal Hocko wrote: > > > > > > On Fri 18-10-24 09:04:24, Suren Baghdasaryan wrote: > > > > On Fri, Oct 18, 2024 at 6:03 AM Michal Hocko wrote: > > > > > > > > > > On Tue 15-10-24 08:58:59, Suren Baghdasaryan wrote: > > > > > > On Tue, Oct 15, 2024 at 8:42 AM David Hildenbrand wrote: > > > > > [...] > > > > > > > Right, I think what John is concerned about (and me as well) is that > > > > > > > once a new feature really needs a page flag, there will be objection > > > > > > > like "no you can't, we need them for allocation tags otherwise that > > > > > > > feature will be degraded". > > > > > > > > > > > > I do understand your concern but IMHO the possibility of degrading a > > > > > > feature should not be a reason to always operate at degraded capacity > > > > > > (which is what we have today). If one is really concerned about > > > > > > possible future regression they can set > > > > > > CONFIG_PGALLOC_TAG_USE_PAGEFLAGS=n and keep what we have today. That's > > > > > > why I'm strongly advocating that we do need > > > > > > CONFIG_PGALLOC_TAG_USE_PAGEFLAGS so that the user has control over how > > > > > > this scarce resource is used. > > > > > > > > > > I really do not think users will know how/why to setup this and I wouldn't > > > > > even bother them thinking about that at all TBH. > > > > > > > > > > This is an implementation detail. It is fine to reuse unused flags space > > > > > as a storage as a performance optimization but why do you want users to > > > > > bother with that? Why would they ever want to say N here? > > > > > > > > In this patch you can find a couple of warnings that look like this: > > > > > > > > pr_warn("With module %s there are too many tags to fit in %d page flag > > > > bits. Memory profiling is disabled!\n", mod->name, > > > > NR_UNUSED_PAGEFLAG_BITS); > > > > emitted when we run out of page flag bits during a module loading, > > > > > > > > pr_err("%s: alignment %lu is incompatible with allocation tag > > > > indexing, disable CONFIG_PGALLOC_TAG_USE_PAGEFLAGS", mod->name, > > > > align); > > > > emitted when the arch-specific section alignment is incompatible with > > > > alloc_tag indexing. > > > > > > You are asking users to workaround implementation issue by configuration > > > which sounds like a really bad idea. Why cannot you make the fallback > > > automatic? > > > > Automatic fallback is possible during boot, when we decide whether to > > enable page extensions or not. So, if during boot we decide to disable > > page extensions and use page flags, we can't go back and re-enable > > page extensions after boot is complete. Since there is a possibility > > that we run out of page flags at runtime when we load a new module, > > this leaves this case when we can't reference the module tags and we > > can't fall back to page extensions, so we have to disable memory > > profiling. > > I could keep page extensions always on just in case this happens but > > that's a lot of memory waste to handle a rare case... > > After thinking more about this, I suggest a couple of changes that > IMHO would make configuration simpler: > 1. Change the CONFIG_PGALLOC_TAG_USE_PAGEFLAGS to an early boot > parameter. This makes much more sense! > Today we have a "mem_profiling" parameter to enable/disable > memory profiling. I suggest adding "mem_profiling_use_pgflags" to > switch the current behavior of using page extensions to use page > flags. I do not want to bikeshed about this but to me it would make more sense to have an extension paramater to mem_profiling and call it something like compress or similar so that page flags are not really carved into naming. The docuemntation then can explain that the copression cannot be always guaranteed and it might fail so this is more of a optimistic and potentially failing optimization that might need to be dropped in some usege scenarios. > We keep the current behavior of using page extensions as > default (mem_profiling_use_pgflags=0) because it always works even > though it has higher overhead. Yes this seems to be a safe default. > 2. No auto-fallback. If mem_profiling_use_pgflags=1 and we don't have > enough page flags (at boot time or later when we load a module), we > simply disable memory profiling with a warning. No strong opinion on this. -- Michal Hocko SUSE Labs