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 A2FEACA0ED3 for ; Mon, 2 Sep 2024 05:16:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 05AD28D0074; Mon, 2 Sep 2024 01:16:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F25DF8D002D; Mon, 2 Sep 2024 01:16:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D9F348D0074; Mon, 2 Sep 2024 01:16:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id B01DC8D002D for ; Mon, 2 Sep 2024 01:16:41 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5535A1C6173 for ; Mon, 2 Sep 2024 05:16:41 +0000 (UTC) X-FDA: 82518638202.10.40B7114 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf14.hostedemail.com (Postfix) with ESMTP id ABF98100004 for ; Mon, 2 Sep 2024 05:16:39 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=D7vMA9VJ; spf=pass (imf14.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725254126; 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=sD2H1ChV4UukIBjfWbJabeqCDSyhleMDE/rBrt8cPWE=; b=cYbvCHT5qDpTWzMSj1QotyxkPbqjiJmdD0rSm4Xq8j4vkTd/ZjQugoqX9bs7exHg1XMlA1 nRTNNJixsjSdpTzYseE/GuwKx1FXx73G6rx5PlFi+cfac8qb2IVOVp/7med5+sIdMlCXGU D3ddi3DAt2hA7O7Ada5O2/ZS1qQk1hY= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=D7vMA9VJ; spf=pass (imf14.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725254126; a=rsa-sha256; cv=none; b=0cQrGQtiOFCpLU327puOtNftzb4Wie9IA7WLC8w/TRwiktIxsFsGUFT4V0YI315nk7gZ1V Z6bRiALTBqg/Yk+8tTkhynLWQHE9XHhFQfZ1Bnf2cPz+nZjgc1NJqXKUdUuMjVfY3O/xf5 1325ak3X354HD/IUNKC5Ri7+AQ/al/I= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 7710DA41664; Mon, 2 Sep 2024 05:16:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0515C4CEC2; Mon, 2 Sep 2024 05:16:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1725254198; bh=1xlmn1CCleSTfCBgJB3zCP9jQCY2zoK1n5+MoF/CsVU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=D7vMA9VJUJwFXhuMZYsQF8m20GzI1hPhtdRH9/AJItHhYVyfbxTGYjTNs4EgrKr+z 4oxLvWk1zZnbWAgN0QtpFQjhan7mhGNBNRprVxLtaoEBTVU38iT4cc3vu+TsODLC7D 3HCiPp9GKDuq//9oLoJR1Wrwr7fSNpHIqtabIbh8= Date: Sun, 1 Sep 2024 22:16:36 -0700 From: Andrew Morton To: Suren Baghdasaryan Cc: 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, 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, jhubbard@nvidia.com, 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: <20240901221636.5b0af3694510482e9d9e67df@linux-foundation.org> In-Reply-To: <20240902044128.664075-7-surenb@google.com> References: <20240902044128.664075-1-surenb@google.com> <20240902044128.664075-7-surenb@google.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: 83cqojtshh6aymqd4zq5p9rpofmmxo7o X-Rspam-User: X-Rspamd-Queue-Id: ABF98100004 X-Rspamd-Server: rspam02 X-HE-Tag: 1725254199-144223 X-HE-Meta: U2FsdGVkX1+PEtcKV1oLH28L0S17f2DU4YfumW2cYX46QRdwEW3HeehY+G6tCv4prfjQdoJ5a4gC/kZ+eylI8FQ11LVl/Uaorlm8EUpCjWuOhSkVARK2Iv/WrW5j1o47bHgpdULclWmIkpxdClPcGHaXkgY5n0aNDg4CbQUbRLm5y1P/xQKc2aN4Vc9u+5jcGDfJZaHcdh/RXuhrLQWQFFN+aQN38EyvjAurGfELhgd2tM+zFW/cvnOl7ADWwilpHuXpyz/cbZPqMmHjzs0U7//00g6WHuwXk8cx3RPqHiS1st69KOnFtLISSBbhL/cIOgrCmKJHxf4yosMIYU1Dyp5GkkNORcSx/Kpux5nvMbYZQ/8h8fbPaDxP8y0RHrWfY0sxNO65DmywvxamlpdKQfc70flBSib8FPiEc4BU1vFmWaQQiclS8KgR+T3Y3bqwkXJik/2gl1U6U8J/OPdkPJKbqK3GrX6W8sI1F+jMKlj2/4gmJe33Wf3ybV+bRJcRsH7yMA6enHEoTizCnUzNJ6s/6ChlU5OMlH3wtCiphMk+5SEKG28NI8/XyUex8Om3RIugDmdCN+ADnhzgPbUXCtnx+OpbF6+sJsfQdqkh3TwSeKBTg8et05GuR8+hwYUASj61OVfrhAI4jjaKZ87VfaF74gJKq288/kPekTC9ZXZVp8ekl8llVkyAvV4rqlu8xmxuPsWZ7PxyAl5dJDpNwuxkcT4wC0UDGpPHaWFrdg0kuBBwGrWdtjVIsiMFxRjDQ7YWIKhtVrx+O5Hbnp5vWdNJj8hzVsducCDtzQRqMFW1zsUkF0ykSxtsMo1+1LCg0xxpRMV0KEgUCimAtErb92B7Zq156CFvMAWiVIXzPgjLrzhqJiZYmE4BX/7deWPU6NUz5jjeRJel6CZ52vXbP6QR5d8lv7VPzkYpgTOXQ2AocU4pogYdJ4Dwv3OYjk1YbIS9TvihmwZdQegLJME isTKNf/F RiUAclKr8pOb/i6+drIvjvjKAL82yoiCsb8Apu0plKPuAVF/oj3icOrOT8PCOag/RPDwcrQaAolVppOWF9SaDct7tcur1grPP/1ONgnMr1b9WIxV0Hda58dhxTq5byXxGYM+2ckiK0Rtt+Ayb5v4hke8L5Kv2/LqF8Vu73riBEgOvLoDkpuCve3RtM4pVeOJ8bL2rPc6xtqMzzZ0mgr2As6jfhKBUBYRGkTwqvCLPrVLVeYtWnX4nreCtBm4VeBfzDJ5p1Kq9BrUj4VQ8YO3XXkdJ8RB/mVDXnvZlnAI4lkD6eYcb66XT7LVUJtLmJge1DvU1 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 Sun, 1 Sep 2024 21:41:28 -0700 Suren Baghdasaryan wrote: > Add CONFIG_PGALLOC_TAG_USE_PAGEFLAGS to store allocation tag > references directly in the page flags. This removes dependency on > page_ext and results in better performance for page allocations as > well as reduced page_ext memory overhead. > CONFIG_PGALLOC_TAG_REF_BITS controls the number of bits required > to be available in the page flags to store the references. If the > number of page flag bits is insufficient, the build will fail and > either CONFIG_PGALLOC_TAG_REF_BITS would have to be lowered or > CONFIG_PGALLOC_TAG_USE_PAGEFLAGS should be disabled. > > ... > > +config PGALLOC_TAG_USE_PAGEFLAGS > + bool "Use pageflags to encode page allocation tag reference" > + default n > + depends on MEM_ALLOC_PROFILING > + help > + When set, page allocation tag references are encoded inside page > + flags, otherwise they are encoded in page extensions. > + > + Setting this flag reduces memory and performance overhead of memory > + allocation profiling but also limits how many allocations can be > + tagged. The number of bits is set by PGALLOC_TAG_USE_PAGEFLAGS and > + they must fit in the page flags field. Again. Please put yourself in the position of one of the all-minus-two people in this world who aren't kernel-memory-profiling-developers. How the heck are they to decide whether or not to enable this? OK, 59% of them are likely to say "yes" because reasons. But then what? How are they to determine whether it was the correct choice for them? If we don't tell them, who will? > config PGALLOC_TAG_REF_BITS > int "Number of bits for page allocation tag reference (10-64)" > range 10 64 > - default "64" > + default "16" if PGALLOC_TAG_USE_PAGEFLAGS > + default "64" if !PGALLOC_TAG_USE_PAGEFLAGS > depends on MEM_ALLOC_PROFILING > help > Number of bits used to encode a page allocation tag reference. > @@ -1011,6 +1027,13 @@ config PGALLOC_TAG_REF_BITS > Smaller number results in less memory overhead but limits the number of > allocations which can be tagged (including allocations from modules). > > + If PGALLOC_TAG_USE_PAGEFLAGS is set, the number of requested bits should > + fit inside the page flags. What does "should fit" mean? "It is your responsibility to make it fit"? "We think it will fit but we aren't really sure"? > + If PGALLOC_TAG_USE_PAGEFLAGS is not set, the number of bits used to store > + a reference is rounded up to the closest basic type. If set higher than 32, > + a direct pointer to the allocation tag is stored for performance reasons. > + We shouldn't be offering things like this to our users. If we cannot decide, how can they?