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 87CB0D3F2AF for ; Fri, 18 Oct 2024 21:57:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 01A016B00AE; Fri, 18 Oct 2024 17:57:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F0C2A6B00AF; Fri, 18 Oct 2024 17:57:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DD4286B00B4; Fri, 18 Oct 2024 17:57:42 -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 BFEF26B00AE for ; Fri, 18 Oct 2024 17:57:42 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 68F2A16029C for ; Fri, 18 Oct 2024 21:57:28 +0000 (UTC) X-FDA: 82688084850.20.D334363 Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) by imf21.hostedemail.com (Postfix) with ESMTP id 853E21C0017 for ; Fri, 18 Oct 2024 21:57:18 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=0A2WN1mD; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf21.hostedemail.com: domain of surenb@google.com designates 209.85.166.177 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729288499; 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=o2RHdVaLA/1r8YT6FR6xHNJRT28I3khxJDB21yaB3p8=; b=sdT1684wFqbeQ48Xt5k8f8VMYjnOGqV+hOG12C9AmkwkwmtMjSIBgu7rahWdrDMLXNQTlH bW0fzQCxE9eSzkgqXmMwgVfAM3PUHzJZpntETP3taKq383e+8CrzZVuxzdTmVd/FXGUQaR vxmY8/LPXqwnsPhrE5VPw7U2sjrHRhc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729288499; a=rsa-sha256; cv=none; b=A5E5VQkP/17DuLdMRmp8K6H8vzQwJJLldmgslp0Cqg7M42c7V9vY/9rJQ9eJk5ms8cTjjI KsTBoVkIbr9WXhKtyXLObsZ24u7Y/AdsimE7dLZrRVUdmvmG77iuIYA98kRMUgVfiuP2iw UhImXjInxPAS+MJYBN5kCzjFTN4NvzI= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=0A2WN1mD; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf21.hostedemail.com: domain of surenb@google.com designates 209.85.166.177 as permitted sender) smtp.mailfrom=surenb@google.com Received: by mail-il1-f177.google.com with SMTP id e9e14a558f8ab-3a3b28ac9a1so27165ab.1 for ; Fri, 18 Oct 2024 14:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1729288660; x=1729893460; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=o2RHdVaLA/1r8YT6FR6xHNJRT28I3khxJDB21yaB3p8=; b=0A2WN1mD/RbW3i6xVi7ivYl6o4d42VbbCGD3Ou2Vxr146USpaGlnrn13DVtSvZ2i5j 4Vyc1nOXC76H4mywzfuKoufY2mFjlaRK0PyOK/2M288L5IX1swgWAV25qWqqsfv23UjE 2mVqLMvkkhEnaAlfhSyVvV32QnyZvA9jmRa/PLygmgApEC346lymWZEP8RDewk/Ao2Yt fAe3TkC7GdTRCW/CnAjCCgqowlWcLsY/uCc78rFSDwltCFvw6htPe7U+pgaLPe5aSZlD 76Pl6I7g6tXC3+0WoM3iw44R2+GkuiWw3uKedibJ717Ba3St6Q7kdlenCgtYKS+gkPbl EbpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729288660; x=1729893460; 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=o2RHdVaLA/1r8YT6FR6xHNJRT28I3khxJDB21yaB3p8=; b=pWRC4boIv1Ifav5JsOsq0EJH0+tIFgkn746yr3XEOLCkyJfbd4eCiSnJ9IcuVamymu 7P3jlBSyyUKdwVZXUDoTZ6eblG72yr2j/c3qQjJGQ8Qc3NbA9HGKRTL0pNMVNfNXoSfr ujPRLxhEHh5C5Mb1fEIBM1wxnJ4zWo6o0V7JbkKj9DOP1aqWrg08tOaYey41y73FE8St PpVy8aioZkfo4wGuvgEcVzNR128CSMcN/6EUm/mihFWx1Ez4xJxEwyc9OItTMVK7I7gJ OphTA5+r77+HdEBQ+BkbnALOMh8T6sGP86YvgBY/p2TE4RLNT63uyvmcmeoZymMXeeKa SJjg== X-Forwarded-Encrypted: i=1; AJvYcCXepmdtms1+ObHySjWH324yS/iOwYH86vbjYImTDNVicfHmUz+8MkKjyRBm6ReX4ZUor8viZCL/fA==@kvack.org X-Gm-Message-State: AOJu0Yx7yhUInKie4UiDvaOcGNM/N4OeqFYPbKCX0bLSEqNzrJaPt6Cy Z2WRQe4qDkBXlTN1muGWFNlKun+6A76wc666tAiAApXhhmcITZHJZJW2ZTO8CPwjgchk1PqDz2a eX8UlyHxotyDXdLVo5E+9YjqD7qdhQR7iVeck X-Google-Smtp-Source: AGHT+IHfPiH22npnOGXJz9+1tdq9zNcHnLzDebicv89VSjhYktk+2yqwb46rCfuG1C6oqvQbOj8a9Ynzf6qXh2Xd8h8= X-Received: by 2002:a05:6e02:1522:b0:3a0:b643:7892 with SMTP id e9e14a558f8ab-3a3fa3d7e53mr317555ab.21.1729288659388; Fri, 18 Oct 2024 14:57:39 -0700 (PDT) MIME-Version: 1.0 References: <20241014203646.1952505-1-surenb@google.com> <20241014203646.1952505-6-surenb@google.com> <6a2a84f5-8474-432f-b97e-18552a9d993c@redhat.com> <9c81a8bb-18e5-4851-9925-769bf8535e46@redhat.com> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 18 Oct 2024 14:57:26 -0700 Message-ID: Subject: Re: [PATCH v3 5/5] alloc_tag: config to store page allocation tag refs in page flags To: Michal Hocko 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 853E21C0017 X-Stat-Signature: ichqnpqmynguc1au494k8i4bcigna159 X-Rspam-User: X-HE-Tag: 1729288638-900449 X-HE-Meta: U2FsdGVkX18xlDRs1wgolR0K+Cpzoj6oi1SyjCDJcm1yJNlHj6RE7I2qqQXcyZyZfsocXL5xEHaM89Zv5XDm8z1+7JZjWTsvGQkcJfyo6MJiBo5/m0FBLqnyaapWEVXZFrgtfg9TZOrpGYobmY9W1FId+UM2sawswcS7sTeXBx0Y6wAzRGA+KYckeyDU1w8VPR3W7ys3cVyks92r6IqqoBTFWOE6TYVs95Xp7eIj2qMFoQCQBxXIUdh4E9zsRAR1Tq0G4uhq8D37a9B9I/GeHk0el9EAeO0SEMbH33coeD5Ml85Z56+EGu3xon+Lf6sIbL8ob/Dxg2ZWfheUsdR5e4LniyJKPXPmBiiUImQHtWvVUtKGWQi0SR0YeyEwn17RIAkgLtEkKz/m7VqLG1Vh/A/uA4NC1KceEiBP/ouIRo4vfCXkunc2Yb+yEqz+hAkHNaqgmpMqzplwfTebv1+ux+7htwHc9N4xqM/SyId/Nur7gkGCms2s67bpc24GFZGMEOOrMve5JP9CJNCDtZk7vFxFF1lx7KTLiV3k3AryjlENEBax/X/j/cMsvrU8N5CCIB3VXCjqnnXoZ2WzP+mp42+h53/OjE6ANvLpPk4nGWVaZObW1pUhZkQO0COEoqE3HD84Ss85Qd+kKhR7ed8VdY1sIsqpOkVUZC2b/Ly7sor9WD3MTMUzSiX6Jzcoar5wW+X3fvGOYp/yX33HvRsr54DZeM9uGZ0iPs6gGk/SkaxryQdXeWj7iGAKGCmv+zIUJSRWUJCP9+bfGl1LXBHeqLeNrG7LipbBoP+e5JQyikhysB/bNNWyQvyHU53EUm6hQKawPtcNU8JBTBwc/Tke/2Ya+jDnGQedITC2BuN1/2Ms3t4LV5KVHskO018PwEiBWvyOo/LiyJ0TBouR4G16WZLk5GgUrYL/msVugP2paMaMn9ZWBOcharAZ7V2XdDSa4UB3B1yhWNVC5Z3HmwC Kxdryzyg Nb4TlTjg4TWzEa4A3WqFwIm8dh+3mJjrCAt223kmhg11ieQ28KvSJTT19TgxNO/b3yR1qGILj264pqWRFrD8uh7bvHA0j3aSs/2jMpMoNzsBWFN5IekuJJpL9oRvJVo2wx6RgFLyTWBoIwmkybULApJEh4/zsqJIHqGpR1nd5oHgQlbpSDZDLFiHeh4ulM/oKQ3Oe8hlySDF66kDkNG0E/1G0NtM+9a+14WkhcXycKctjNkiqTjYQ1t160uIyTqHfaOuEZ4XTCTys6rb+QbiILRBKc+gvNCWLdHcSoLmQxO+GZbmmn7yBS+Ih8t/RoSGSi/mtO6MhLP42ry5s4AsVPr6CBnyVpUvypboM 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, Oct 18, 2024 at 10:45=E2=80=AFAM Suren Baghdasaryan wrote: > > On Fri, Oct 18, 2024 at 10:08=E2=80=AFAM Michal Hocko w= rote: > > > > On Fri 18-10-24 09:04:24, Suren Baghdasaryan wrote: > > > On Fri, Oct 18, 2024 at 6:03=E2=80=AFAM Michal Hocko wrote: > > > > > > > > On Tue 15-10-24 08:58:59, Suren Baghdasaryan wrote: > > > > > On Tue, Oct 15, 2024 at 8:42=E2=80=AFAM 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 obje= ction > > > > > > 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 degradin= g a > > > > > feature should not be a reason to always operate at degraded capa= city > > > > > (which is what we have today). If one is really concerned about > > > > > possible future regression they can set > > > > > CONFIG_PGALLOC_TAG_USE_PAGEFLAGS=3Dn 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 ove= r how > > > > > this scarce resource is used. > > > > > > > > I really do not think users will know how/why to setup this and I w= ouldn'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 user= s 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 fla= g > > > 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 configuratio= n > > 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. 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. We keep the current behavior of using page extensions as default (mem_profiling_use_pgflags=3D0) because it always works even though it has higher overhead. 2. No auto-fallback. If mem_profiling_use_pgflags=3D1 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. I think this would be less confusing for users and will avoid David's example when performance is unexpectedly degraded. The default option will work for everyone as it does today and advanced users who want to minimize the overhead can set mem_profiling_use_pgflags=3D1 to check if that works for their system. WDYT? > > > > > -- > > Michal Hocko > > SUSE Labs