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 18BE7D3DEA0 for ; Fri, 18 Oct 2024 17:45:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 864766B00B1; Fri, 18 Oct 2024 13:45:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 814476B00B2; Fri, 18 Oct 2024 13:45:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6DBDB6B00B3; Fri, 18 Oct 2024 13:45:53 -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 49AC76B00B1 for ; Fri, 18 Oct 2024 13:45:53 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 7D378A07AB for ; Fri, 18 Oct 2024 17:45:30 +0000 (UTC) X-FDA: 82687450860.29.8459ECB Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf16.hostedemail.com (Postfix) with ESMTP id F1C0118000C for ; Fri, 18 Oct 2024 17:45:39 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="peQ/595v"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729273516; a=rsa-sha256; cv=none; b=cq6lwqRpUbsuDNp+4BVEPFwL9j7ta8ygdZPlLoY8F682GreLXRXB+PLWMWz87hQ8KDJwA2 lG/8UQJR8CyGPmPRYG2kazfkViem8+KC4JBopq7MlSYrhzco2Tzv3/sExKm2dmn5SaL3g7 0dP2dybpliCbSHa83LfmoWg8v7Z3sjY= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="peQ/595v"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.160.169 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=1729273516; 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=2HNohuL1u3Ke6VUFgUqBJ1ousiBndflpg7Tj2zyNChI=; b=isa6wJV4lHe1lHZZhlN66kR5nklWkEv856iPleAoSwBKytpg17MZBQiuvaVV1ecDS+rh+r Od/jXnog1061hqmtQQF/9em2/VSSCjZcahMw7NESijApUISde14n8j1SubEef/VKbfkgIs bBDlIEyfPI6ksO9nrA+CPW8qrKHVeUY= Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-460969c49f2so27931cf.0 for ; Fri, 18 Oct 2024 10:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1729273550; x=1729878350; 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=2HNohuL1u3Ke6VUFgUqBJ1ousiBndflpg7Tj2zyNChI=; b=peQ/595v8aYdCLXXpz9v2fO+HkpIqgfU9C/JwYLrg5NiX+/6HglcXbA0suL8f74Doc nigPCj0D2FmNUpwEUwWsbau/7IuA855KjiRP40yliag5QoT30QnzToQxW/YodrF4QndC 8RCilrH+wcHHS46LQtPeZqgsDaRCSvs0g4d0J7X9OfGtCJHkhWrNXAOnFX3YaklvvHQZ PkSNYK6POImSlIV5FwHOWjWsEmmrXuEIrKeub1arHLKlEAttzJ8/LcP+dkPOYrFLT5kO gFg4CUb5B2XGwLBVhHGbF7xyJs+tJjBrSiwMmNwNMeTT9Fn1FpC7jF2It6Akswd4V9mA 5dKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729273550; x=1729878350; 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=2HNohuL1u3Ke6VUFgUqBJ1ousiBndflpg7Tj2zyNChI=; b=J/pVXfdRmFiYGbyVR6b2JBemRRzwyMWuA2n/D4U/idRF3NF9rs3caLxsPF0yCQFXn0 OwOKgx6FqphSkI26rmSc5i0Iu30qmgDdZGqNYFXamVkj6x3jUpAXmnAObVux50Ia2Z33 jNWLRKD5Bk0RBIKPP6b5VdAuSQQtBFAHOg65fYYSVFVxR2+aFcAxRLSiKM87CdI0QzuL rv33bgbBirRch1L1/+9cDlszLNe1hgKyo9auKYElEDmE9uhlaVMdfgR+rTZOSSc4CwgJ agPk5vNgBMPyKwi2AkBGj1eW/OrfNj8sVZnm72u9Ogxg8N+L9Nh/Bjp7sVozRt5FHRL1 05mA== X-Forwarded-Encrypted: i=1; AJvYcCWAmldu4bfG5JkKgypfK4LyMI24tqKtpP2ZzViJkGNCQlYmM9/8KIgoTF9ixpQbMrddz1XsC+CJAQ==@kvack.org X-Gm-Message-State: AOJu0YwCI65cb4+vjDCCeP8g8XIw+4O7E15oN+KuYLwTORTb2ojdABdB 4AygBjMqurpMESjMrTtf9y3mlKOs2YZuQB0eTVz7oGqUEkXhxB2PEKO9tFUJMru1XMBo/eRg5af JrAEsT/aB55R6hwNMFNbEm0DXNK2u5vl7ZgNh X-Google-Smtp-Source: AGHT+IGLh5tN3Mn+UeRjw6TTi6Ilr8u+U81XwFGNFN94aBWeUXT1vXcpiZD1WFcjvHGV6Z3iM3U/fjqB5uzAQX6cuG8= X-Received: by 2002:a05:622a:2a19:b0:458:14dd:108b with SMTP id d75a77b69052e-460aec26827mr3223491cf.13.1729273550039; Fri, 18 Oct 2024 10:45:50 -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 10:45:39 -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-Rspam-User: X-Stat-Signature: 8x8ax56of8xdkyxnt7obycn9zqstgtfe X-Rspamd-Queue-Id: F1C0118000C X-Rspamd-Server: rspam02 X-HE-Tag: 1729273539-625516 X-HE-Meta: U2FsdGVkX1+R32DCnZldURAx9zpMhO0FB0NtXej9ffIvUSZXKaiWYS6cmVjUh5uIQfWozJ9U8byLl+py76w28658d4RZrCk/yuJUBTS56NfXvrH5IcTcI8zPWYlsPo2xH3mcpSwr2E3W7Lu4AbDtTYP5YijgNIeoY4nTaHeN3cQy/QpRKAH2HgpmMsPQM1P7jbE3DlD1v8PTlYsKsOCLZHiBwyTKc77PXmykvRpIhnDqbmOhW4sMztg4IJC7upvg7RUv+uxYVJAt9qAAIsxlaBoSv4aZr6F6n4C0BtNruSWRjkSdhkxjKDXoVZ6wMsp2api4D3yafAr1TqgRK50zmMwG4j8IaxiyV5fieBqgVm+y1ur9e1q2AkEJRJMKP9WieFwvS0jRkwancjJuXGUvkBxMmmxESrWz8jZCtsw3ekp+Y3iA1qzfXrP82dEE0txcTktaxqDL21YM8JDk9mONJmljbxrsyQaL/9ha2WSoQR96aUwKZqPaZxOF34/DKq0b5VW6Jvdml5DUPBzycWkiwYCDARjwMr8EF/rqpLA+faSwmowVFeooV/sNhaNI1B6Q5zru8aAwQSryO47lhM7cbl/kZ4XVADmCc9SXu43xh0mdWkxSiaNyljK6Ul7hyaftmPBtfBw1TwUfeJwvcsI9jYgA0t5VmU6r1DCy3RAP0tiy8w7aFAKseNSPnmirE1C0rCDgC+eV21Wj0UCZaHm3nIxwsCMlqfuvkVU1JUH0KoGrJ9PMBfr3kSNgGA5eXt/Lmj8uMwsFzsk15V4NPGmq20kKG0RIwzOrMVU6+gr7a23IgjXwyFFvYSH6GYJA3WEN7NxmuHVTZLrTTDJl+3dlm68UcYA5PTY9W9tpZjVo9EZCMQoMZSNz7vZui2PQwlwkZPrD+VVbTc+wA08y4dKkm0dqjGKHNQLQApprgkHE/jrEhad3BOSOYoPhEgX6uV0r4my5bMuaxoGhwqh8RUL KAbZX9vZ i/et5JL1yxdWudgR/AqvR3IKBh0cY3HyH211SP0hIg3YV9UiOvXBWfUzG2MKOjZMJshzh4fZ6xRbW0cxto6KNKOqURvwzwMiQSEU49Yu2s5KVX5dpvV6X9u21B40Pjn+XptZ/0aYyjd0Ui2Mtn8itYwOnNtLTJ3LyBTxXbxs1F+gBj7N6jtZQAej2zBa4AeXkDNSzoQbZHDe2/4rRZbRth+COohZ8HhZUVkEqEfRAslCObiX8tIudxvKBcdgeNuDw4JqCcp2lwtQ77EUGDTU8THWPrtAkaJ5EgzPqV91fu4SkHYn5RgI4mWf0vzsRc7e19oaTQna4xX8OFVQ= 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:08=E2=80=AFAM Michal Hocko wro= te: > > 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 t= hat > > > > > once a new feature really needs a page flag, there will be object= ion > > > > > like "no you can't, we need them for allocation tags otherwise th= at > > > > > 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 capaci= ty > > > > (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. T= hat'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 wou= ldn't > > > even bother them thinking about that at all TBH. > > > > > > This is an implementation detail. It is fine to reuse unused flags sp= ace > > > 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... > > -- > Michal Hocko > SUSE Labs