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 51223CD4844 for ; Wed, 4 Sep 2024 02:41:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D90358D0218; Tue, 3 Sep 2024 22:41:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D3F608D018A; Tue, 3 Sep 2024 22:41:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C076E8D0218; Tue, 3 Sep 2024 22:41:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A39AE8D018A for ; Tue, 3 Sep 2024 22:41:31 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 495C4160BA3 for ; Wed, 4 Sep 2024 02:41:31 +0000 (UTC) X-FDA: 82525504782.17.3C338D6 Received: from out-175.mta0.migadu.com (out-175.mta0.migadu.com [91.218.175.175]) by imf02.hostedemail.com (Postfix) with ESMTP id 55A7C80005 for ; Wed, 4 Sep 2024 02:41:29 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Wp8WEIrm; spf=pass (imf02.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.175 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725417595; 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=bbtBqo1EZbK6Re3xFNuGqtBqb/6K6cAryDz++MpLXTo=; b=pOmKvaBsPHY7gXHnHVur5PfxAMumP5ctPbHlEqGeaMcgFPhzXd2JaXQxGiLhsUA4al8xUC /OB4WLpk6n6hE6V0f2eT9CnOfcgdVRKCX2NWasvRh/oWKyh3pqNCMt0UvDhGwjhfkz9tsc BtvsUbQ5XbICUTBwveif/kQf3eoU93A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725417595; a=rsa-sha256; cv=none; b=Gda0kHZqryJstpzaJ99TM967qFzFIlHR8PrBF2dCGRJ+tIZw4dkRoZ5NOLgjwjeGj2EgYl ZvHh1NQNYqvKgDAEa/at2wj46ku0A5tyqs6tL6AmY1hJPx4LkjqFxTt+EXHXwmP36NL9Ft UF5A1hXA95ceaAjNFbNUnU9Phxop4Js= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Wp8WEIrm; spf=pass (imf02.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.175 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Tue, 3 Sep 2024 22:41:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1725417686; 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=bbtBqo1EZbK6Re3xFNuGqtBqb/6K6cAryDz++MpLXTo=; b=Wp8WEIrmkReXG4RhZ12/r6AgNRaXvsgdQozHpFAg+EXC7PtTK3bO/7edG48d/BdlIvY5QG XhudROR/T2cPC2zMEQYpk3yS+E4RhiSIvj2qCHNCmjaGkXTE64LZ2D/jWaZBbc6vIYdOvP rbDsuFPLABfR5j0x1zfq5OKMKc3wI20= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: John Hubbard Cc: Suren Baghdasaryan , Andrew Morton , 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, david@redhat.com, vbabka@suse.cz, mhocko@suse.com, 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 v2 6/6] alloc_tag: config to store page allocation tag refs in page flags Message-ID: <6nyab6mvkda6qwq7pk22osychqwnogecw2nhk3tv7dbhxs6yob@zhnfndo5bh4f> References: <20240902044128.664075-1-surenb@google.com> <20240902044128.664075-7-surenb@google.com> <20240901221636.5b0af3694510482e9d9e67df@linux-foundation.org> <47c4ef47-3948-4e46-8ea5-6af747293b18@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <47c4ef47-3948-4e46-8ea5-6af747293b18@nvidia.com> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 55A7C80005 X-Stat-Signature: jgokgpqiuuwq5hbob9wbzcqqhq1qb93m X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1725417689-685054 X-HE-Meta: U2FsdGVkX18xZFtq9vFqhkkU+OHTxBxLAzrFXxauHzCvXq1nPrFXSnE/ZGzrvDpLHxZ6BvBAaVrgHBsxAFI0wCh6J3kfxHw7y9KKc/Rzleslo0c7QgAyDum0BtiWzgKg4XZSgblPT4dnllxLs1AwzxvvtMvZRz1YCAcEPoIOElhPUd5KeuX3QjizCXHpfZldgKL3dL1ZLOFZpzcFeuU9IA4MoB7TVejnRzkKl9Zo9QXwRBr2wy6nn1TLbNBm/S6cYCEeD57MmKZo8fVaQSoN8re0A3nN8cly1GK2i2hXPwuvGPHleKdMHn9a+W3Kyvx5kFR6ULx5+QJ+QzD/Ce8IUy5ai6+Mgnms/M93qmmos4/bxmK3OQt0y73bFZENGfs/W+MtvoNwAVKwjvFc6WccHAO892yzS4aGRQ6Qsw3neA4QaCmS8AxQdnrjn5seuF/Zr8RIwQUQSlPHqrx68WRZwqQnkPiAlGAfsetGDis9wyv1uIW0x+XXlIvf9GpgW31fDP0p7wj7FEh7BTF4ifU1B6aBaiRgsPkSha+FXLCWuh+2Wosdvm4oEV6qokWp40fNCB2NFsDB+lan0NFJA6I9uHwaYz0wmuZM1s6oxzLkurW+zjFnJ0F/8KAlYCVEK3t+v1lr1ja7I4b7NVLRvd39G/qs1In8rfo+pgX1eSCSPWYx/TizLB3WS1I1bZojBb23oe0r83Op14dp7GdWJKaNGAfSRmBbZWYrGcjZ0ziQMBSkW7zcNHgMugXTiHAzgx+5YJyrPqlVgT5HdJ1yTz9Rx3LJy5gnSd+v2axWBrNi++cW+kber69IoqyOvs1TygM6XXkv9pVMsLjoF+4+/lVVauRgkY8E2iC/VUPTB6L7RKDbogdcwh4W4tMv+htVbz4wwcmA1EYix2sECoEmIXifEBOIzhoMaSA4Ibkl8olUlmoFyEuCB3oFcA6c782u9h7YW76oN4K8ABPuyO9pcP+ eNrQxRuk d9YLcNPBtnSZylYbfeAQQnxM1/eieaecYVIfX87MqvVruWO0yA7MQlBOqL0XNGnjgu+34qHTl5A8ZD+Ih+iRszYkvtKOQwiPKO24n2QqPeTAh+9nIIgrctwPriWMf6G0UIRToVuZKWLG3984sTPNlyWvADWwRxX5FK8maUwtP8krSE6+7dCT1IttX0kxsPFvxWEsWMYlqVNodx4WpjmNgfyoKd31tAGapxjkW+rbzB9HHAqb7WA4BpRqhLfeqFw1fk0pfrYRpvDJT3qXBv6SiaNnQKBHJbk6STQAVzeYc961ZMaHHP1bl8PMOCA== 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 Tue, Sep 03, 2024 at 06:25:52PM GMT, John Hubbard wrote: > On 9/3/24 11:19 AM, Suren Baghdasaryan wrote: > > On Sun, Sep 1, 2024 at 10:16 PM Andrew Morton wrote: > > > On Sun, 1 Sep 2024 21:41:28 -0700 Suren Baghdasaryan wrote: > ... > > > We shouldn't be offering things like this to our users. If we cannot decide, how > > > can they? > > > > Thinking about the ease of use, the CONFIG_PGALLOC_TAG_REF_BITS is the > > hardest one to set. The user does not know how many page allocations > > are there. I think I can simplify this by trying to use all unused > > page flag bits for addressing the tags. Then, after compilation we can > > follow the rules I mentioned before: > > - If the available bits are not enough to address all kernel page > > allocations, we issue an error. The user should disable > > CONFIG_PGALLOC_TAG_USE_PAGEFLAGS. > > - If there are enough unused bits but we have to push last_cpupid out > > of page flags, we issue a warning and continue. The user can disable > > CONFIG_PGALLOC_TAG_USE_PAGEFLAGS if last_cpupid has to stay in page > > flags. > > - If we run out of addressing space during module loading, we disable > > allocation tagging and continue. The user should disable > > CONFIG_PGALLOC_TAG_USE_PAGEFLAGS. > > If the computer already knows what to do, it should do it, rather than > prompting the user to disable a deeply mystifying config parameter. > > > > > This leaves one outstanding case: > > - If we run out of addressing space during module loading but we would > > not run out of space if we pushed last_cpupid out of page flags during > > compilation. > > In this case I would want the user to have an option to request a > > larger addressing space for page allocation tags at compile time. > > Maybe I can keep CONFIG_PGALLOC_TAG_REF_BITS for such explicit > > requests for a larger space? This would limit the use of > > CONFIG_PGALLOC_TAG_REF_BITS to this case only. In all other cases the > > number of bits would be set automatically. WDYT? > > Manually dealing with something like this is just not going to work. > > The more I read this story, the clearer it becomes that this should be > entirely done by the build system: set it, or don't set it, automatically. The difficulty is that we don't know how many modules are going to be loaded, and an allyesconfig or allmodconfig is going to require quite a few bits - it's not something we can really predict or calculate. So there is some genuine trickyness here.