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 10A28CD4853 for ; Wed, 4 Sep 2024 16:21:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7EC078D025E; Wed, 4 Sep 2024 12:21:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 771C88D0253; Wed, 4 Sep 2024 12:21:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EC0D8D025E; Wed, 4 Sep 2024 12:21:34 -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 3A3B28D0253 for ; Wed, 4 Sep 2024 12:21:34 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CDCD08179F for ; Wed, 4 Sep 2024 16:21:33 +0000 (UTC) X-FDA: 82527571266.03.BCB5366 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) by imf22.hostedemail.com (Postfix) with ESMTP id EBE11C0014 for ; Wed, 4 Sep 2024 16:21:31 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ZKalQCs2; spf=pass (imf22.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.174 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=1725466764; 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=+JqXoB8jLlVYHGDq0AwOaLEhKJQ+zif2aGJ3V0UPjuU=; b=rQrC9o/nunyNfh84pNkysylJaYsTbKtg9qGQDUCPgcSAMCI8F8OPYU/R4eNpio1byIdHsh GYxVgHLhaRUr+fS7Ijm6Y7qGxds0koWQVpfXZ2INDB2KXMwROmFd5LU0xNDfzw2q7i9brA EQbKAXgtuP05T/OAb0QrwZ72ONvNvHE= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ZKalQCs2; spf=pass (imf22.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.174 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725466764; a=rsa-sha256; cv=none; b=jb5nS7IC3mF1rC0GGlNTM2sFNRweF0iO0eBM5OkDM/zX7TUyqndpK71IfHN2BMOdP5dNKm dpIUIwjRaex6Ez9kDfyF/7PrhFuyfo+v1BTY50xlZuV55tdcr+m/Z826fb/Qh7z/FvUqif bKWZPBbWZX4puv1+tj3N3Y2oxE5cVD4= Date: Wed, 4 Sep 2024 12:21:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1725466890; 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=+JqXoB8jLlVYHGDq0AwOaLEhKJQ+zif2aGJ3V0UPjuU=; b=ZKalQCs2XotYejr6ODhzpK5d5qiOQWI8fG2cLDtbYmw4IONIaNYn93REWMvnH0cYeVpIuJ z8GxAv+Z11/wJApNg/ocfoL/qBl2DwkEyz+sBVXzPUS2l/HBzmGieWMNONTsg3YM6qeJ/O jzTf6aWAGuxeII5QaZa9L3t3Ov8Z6jc= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Suren Baghdasaryan Cc: Matthew Wilcox , John Hubbard , 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, 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: 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: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: EBE11C0014 X-Stat-Signature: 4yowd7zdzpcz19owcn7upo8ynj9buymm X-Rspam-User: X-HE-Tag: 1725466891-904460 X-HE-Meta: U2FsdGVkX1/wuWpi/sOTTWy4IKiTrmFOPicrRS/npBzUmeuavnC69D4qKP+w0Fmwf3bp7/ZGlCn6bWiaZzmtyXb1h0VAB/cg4hvZB483AcTixl5BsZUNl6+Ue+MC0HifwvenFsDoutP21Gu/DITWfh9jvrMf5MbEtEmuW1kkbJLVsbnkQmR4eH4rdGxhBUbC7lb7gpehqKZisQbJRolOgv0g+fgH5J3mUIsad5qlIYeDVXHGkuNRO3KjW9EUzOdgCiTi/cyBp1Wkwf/hLDL+vqTl9MOIEMT5aivmW/5mamrNGg0WSafEzgpjWG7ELu3ka26NEK1qXLTnztZHdwBUO1Ik+YuCnIWZR4VJvUptbI2tSJJkRirev2B9mgsQemw8NuOapYfcEP3Z1dYrewNu9vscJsRL/s4G9NvRcKDHsnp6FX8Jk3fwFO/N2016SOzQIxh+G+taD7l1lBRrepNPMnlIr/eIQ9zta+bCV/Hi2xZ/BaROJL+dK8TM5moIZUrHdia6FQLBi/D7QY30p/OwUoZ0FcnyC5JEXS7pzAjjFYeUWCrHLKsFbL1uyGNs8uVQJWuSxFLrXbPFqdX0bipQK/D1FEMqgjpSNzsUQa9nZ3tNl5a35VBjdmvsGTSGxWbpIHAFeR5AaxVXxlJ8FVgQ2M3TFlh6sOmc+UpEKPOsxM7/9v7O4ry6SM0Mo/1jPM8+/7KGgErjw3k4li/4GjFBSmqwZ0N3wBr8sb9O29l1s5vhpBDpo2gpoqJXuPDbRcUMqQmWHPCL3xRvERBh8F/y222biJ6d/0xxDP1iymLGSGUbnLCvJ/p+No0jt2lbHSq8+3mtR6lJlRzDxMGTUvgXUBoi0Yi4XWc2al8hCB1Ynh06rvLp3gGsdz7kRddTfHD0jl3N/jCoe12JlSQR4sgyckZ1GHgKQ5bI6vmydSzmLp/gw4qUQiHB0sNF49kfhg+OL5/MX+wf/G4RvwYR4SO jbvN2vh9 WCDPvdQs7us/5W36Uu4wNODSLoN6lfqmcsv1As7ZQLpTbfnrwRIm/rUkousQJlB+z9DJrx+xhekfqViex5sPPIzbguVEvPD+rCZJCgXyz3ldFK11jiNgX+s64QNqZTa2boTS18tHg+KrpvGez8JykkZc1qkpChBGjNk16ykirLHukP3xDsgCrwXGumZTbA5ntCVmBBTnvoxCKf70xcH7Y1RTsQgpfNWK4fz2jwpB3a7ZFs/HbHfWIUpfnqoQHFM85ooIC9Hi1TKE/eEnDTtcu5ow4rA== 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 Wed, Sep 04, 2024 at 09:18:01AM GMT, Suren Baghdasaryan wrote: > On Tue, Sep 3, 2024 at 7:19 PM Matthew Wilcox wrote: > > > > On Tue, Sep 03, 2024 at 06:25:52PM -0700, John Hubbard wrote: > > > 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. > > > > > > And if you can make it not even a kconfig item at all, that's probably even > > > better. > > > > > > And if there is no way to set it automatically, then that probably means > > > that the feature is still too raw to unleash upon the world. > > > > I'd suggest that this implementation is just too whack. > > > > What if you use a maple tree for this? For each allocation range, you > > can store a pointer to a tag instead of storing an index in each folio. > > I'm not sure I understand your suggestion, Matthew. We allocate a > folio and need to store a reference to the tag associated with the > code that allocated that folio. We are not operating with ranges here. > Are you suggesting to use a maple tree instead of page_ext to store > this reference? yeah, I don't think the maple tree idea makes any sense either we already have a way of going from index -> alloc tag, this is just about how we store the index