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 2FBEED15DA9 for ; Mon, 21 Oct 2024 15:05:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AC5F26B007B; Mon, 21 Oct 2024 11:05:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A764C6B0082; Mon, 21 Oct 2024 11:05:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9168E6B0083; Mon, 21 Oct 2024 11:05:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 7391F6B007B for ; Mon, 21 Oct 2024 11:05:33 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D79BC80541 for ; Mon, 21 Oct 2024 15:05:19 +0000 (UTC) X-FDA: 82697932758.27.BAF44E9 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf16.hostedemail.com (Postfix) with ESMTP id 8F0DC180021 for ; Mon, 21 Oct 2024 15:05:16 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="QJb0Nn3/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.160.178 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=1729522966; 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=50bzoL0E5RW9jtb3/55tHhkokdpjPWuz5iPr4mnKF78=; b=tBfYYk/DTzS1xls3k66pI5VH6shUvgsD1o7cMqTkq3Is8DATJPhYxGMgC8ho0UEGHRS+iq MeoUOpR7jKXs0pEBWTb93YQ+0dZ9tgApKqFDuzykD0zoLNs450q8nSeT3IcwIZLy/m8YDn 9kdiPsS/25T84VLO2ZE4JNljh2fLXnk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729522966; a=rsa-sha256; cv=none; b=OqZiucwbt+9MI160gmy4eDp7FPaM4iPcHJYrMZFcKVBDLiHogPcfBujkgIILWnF8W9Jsi4 Rf1KEMaEqcVrUj5k5h5rAg4kiMs0xlnEJGSomvNchOL0uUNKQGuCGF8FYrbIN6RkYdO7xR ezmgu+wyql/IBglRrO1wXEHLFiwbdWY= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="QJb0Nn3/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=surenb@google.com Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-4608dddaa35so442821cf.0 for ; Mon, 21 Oct 2024 08:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1729523130; x=1730127930; 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=50bzoL0E5RW9jtb3/55tHhkokdpjPWuz5iPr4mnKF78=; b=QJb0Nn3/YOE5m9Rt5/b1bfgBp7VoJtSKljOWScSBjjodNfI0RSif11BtW+a4vZC/Xw jZoocsm5zXUlzGZhBGcYy8iPKSDbr98yKPcQbtd8va/gARYB0q5DqcM4JakVDbcTvjRH nzri/OzaBlz18LCzeM/x5NmUxjXwehMlzkzVx8oa2OX+icgftQSUi5NV4PO7kjhKxIMk HZXN1QTOPU4/Y7e1tH2Dp03ZPdqW7F/+Y/Rva5EFJr1jE5OzpHODcQrghqTo0E19pkK/ JtbCSvvQPLEtsXo+vwFCs3YiXyT0QDu+Ud9evBJOsMX7lTA/qu9ZnMXOvtp757Y5ZxOV OpiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729523130; x=1730127930; 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=50bzoL0E5RW9jtb3/55tHhkokdpjPWuz5iPr4mnKF78=; b=ScoipqYaGR4+v/LVqKCSx/WdjeFBrk9FCBLjgfoBUHKExUGvupOMk3hvONnVOVAwSH PHSU+UJXoIn13q1DoBeFmsr13FU+Rh7o0qf3WYv4Egetsa9E9MT1uh/ebJ5dWza7vSn1 IgFziO1VEa2EDO4Ilu1vOv2WjoJEELm30upqHzZq7i6d6D4MM07yXk1WYJ2+bWk/kkY+ BoHL/vIwv4X2dT9mwWZ2d7NBzVJPHujUdi67ObbhPqlapcYlbYCcprJ4Md9maUbpGTRY x+xQ/enybL/sX0Eyazf889k1XTMciKUJK2v7Om6AiXy69sVUKn4Tlw5kYTs6n++HK/2Q 0WGQ== X-Forwarded-Encrypted: i=1; AJvYcCWBf5BX8Am/CZA9sfXzcrvRa7W1eRPwKKSY6IA+rffpu7IcRfZsyusWqJNz8hNcMszFtIypBHeYYA==@kvack.org X-Gm-Message-State: AOJu0Yxs2qy8IIjuF9PHRoh2mvpjv7tMTIuwsWIQwVHrTL40uiHaErDa YahFgF93QDJVrko758Lc8WsoPiAZiayfdY5zKXhn5lINQR9BKKzOd4ccuZcWRDY0Y2DlikMLOyp 2XXBdegJZjOPDBwTRmmnVae7FvuudF2K3Hkkt X-Google-Smtp-Source: AGHT+IEOXV+Q7vMIloFDPvxSVsyITVEcRe5763BxgPsFvYZ2aNgQJzPh1q4g46HKK2Ge4bEfemTrl3UiZHhHOGQk7cA= X-Received: by 2002:ac8:5a03:0:b0:45c:9d26:8f6e with SMTP id d75a77b69052e-460be5cce66mr3744761cf.21.1729523129971; Mon, 21 Oct 2024 08:05:29 -0700 (PDT) MIME-Version: 1.0 References: <6a2a84f5-8474-432f-b97e-18552a9d993c@redhat.com> <9c81a8bb-18e5-4851-9925-769bf8535e46@redhat.com> <62a7eb3f-fb27-43f4-8365-0fa0456c2f01@redhat.com> In-Reply-To: <62a7eb3f-fb27-43f4-8365-0fa0456c2f01@redhat.com> From: Suren Baghdasaryan Date: Mon, 21 Oct 2024 08:05:16 -0700 Message-ID: Subject: Re: [PATCH v3 5/5] alloc_tag: config to store page allocation tag refs in page flags To: David Hildenbrand Cc: Michal Hocko , 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: 8F0DC180021 X-Stat-Signature: d7z4pniij1ppph155b1fzydtyacgr84m X-Rspam-User: X-HE-Tag: 1729523116-832310 X-HE-Meta: U2FsdGVkX19mtI50V7fkeZjG9VK9v3jpvEDi4EznZ0ssp3cqg67XJcH0dQOu2/f94FAvDlKq9/oGX5q4Ke32sR3itJnF8hkydCYiy5qSdSj1c0CTX4W9A6eIuStZcaM1jVfB6EEn40AmOS3+qb6a0Pe9PUgw6yGeeWFmAlE2sesOZBTzWIt3S/DzfFMQvufQQrjCla+kdAYarNRgtm/KM/sK3fkv8RXXYqA0f4n7Z5zrq7WasOzlfYoEEa1LlOVSB2kuD719WW79WJ0vqprnyhn8Q/3diKSCH2eOZtry+Cy8GabaGOnBI+Cq7dht71RRbfMzZ3E7R9ATcLSOpNLBhZKFqfnsRdiGo5iZsWoPBs2I2baUmpmCqLtP5h7cs3IyCESpbK9e4vrvK0xXHnTI3Ib5Zmk4dXB/WI+VspoAy3vFbjiIFzVW1R4aDdPj9t+BZ+y8MFyXTH1Op3MfFHXwKh+OdmbEF4aKbLbOTj5xoADGepXgGm4PZ3R+oxHY+L4N0VbCOjuq8YnfXDXqLLbpBIx/J0q4s14wTY1XFFHc3+j0+xi4kqqnisXergeMywI8d/tbcojlaYSJ78ZPtV2PsBpCN1vlLQq+jK/lbIQ4NwiMNbsjVHXypoCCF9VYazHTY8LaiMIE7PUtESzouV1SY4ETgRN+5lLPKYWc3wvHE5QK0kS5tG26MJd7vb6NxBCsp4Qp4BAdXrNJB9sMRkHNkFVhuR0V+YyLBRpC190Es0aMN4K8eiAvg/C/4OQqjAhdRt87blHoNxNWSIHOtzDYFbYpeOGoan+HCaLtKXy7k9MktG7opVRmW4pY8ofLahlg0snCDRgVA3PzFhSJTGUFEQ+ivyqoVBzlBSeBb7LwAL1rDLTGqiRdvP4oBZrU8bcRmRgiRb6Ps1JwGV3r6zSd44yCvZm05QBcovphdD5yb+194vwDevC6o8w8dW/bGLNSaQdGlAML2P2vqBirCvC brS9NZZ+ ljxJId0KvBPiYkfOa2mwg+PyyeuLtEJBpgsTK8yyCWyd2ldmgZvNOuYjmMT+sf+f93z9WGZCn8Vc3txa5JyYlLQoHGifWmdLJYENRu7zGBtyEP28JbOaAedPD/kneHVkXdi96+INql9dDQxcX5gwdFcTDQbJf6kcRlf4IEXIp3Ty+Dt3U93wU5OGe0qaJP8vElJy88NworIUr6uBn2xnw0kq6pNL2OlUrcVxxfmsRfkTp709QadI83kpPUsJdQ2P/AmWmvwljGBdkhHES+Y2jmudkEoGronZrOgw2t9xL30L6s0jjRN3h3VXcIFIyKg8WmWEqvRHchHYxwOx63IoGlCZV6qXzFwNs3pPX 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 21, 2024 at 2:13=E2=80=AFAM David Hildenbrand wrote: > > > > Am 21.10.24 um 09:26 schrieb Michal Hocko: > > On Fri 18-10-24 14:57:26, Suren Baghdasaryan wrote: > >> 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 wrote: > >>> > >>> Automatic fallback is possible during boot, when we decide whether to > >>> enable page extensions or not. So, if during boot we decide to disabl= e > >>> 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 b= e > > 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. > > Maybe we can reuse the existing parameter (e.g., tristate). Only makes se= nse if > we don't expect too many other modes though :) Yeah, I thought about adding new values to "mem_profiling" but it's a bit complicated. Today it's a tristate: mem_profiling=3D0|1|never 0/1 means we disable/enable memory profiling by default but the user can enable it at runtime using a sysctl. This means that we enable page_ext at boot even when it's set to 0. "never" means we do not enable page_ext, memory profiling is disabled and sysctl to enable it will not be exposed. Used when a distribution has CONFIG_MEM_ALLOC_PROFILING=3Dy but the user does not use it and does not want to waste memory on enabling page_ext. I can add another option like "pgflags" but then it also needs to specify whether we should enable or disable profiling by default (similar to 0|1 for page_ext mode). IOW we will need to encode also the default state we want. Something like this: mem_profiling=3D0|1|never|pgflags_on|pgflags_off Would this be acceptable? > > > > >> 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. > > > > Yes this seems to be a safe default. > > Agreed. > > > > >> 2. No auto-fallback. If mem_profiling_use_pgflags=3D1 and we don't hav= e > >> enough page flags (at boot time or later when we load a module), we > >> simply disable memory profiling with a warning. > > Sounds reasonable to me. > > -- > Cheers, > > David / dhildenb >