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 053C5CD4857 for ; Wed, 4 Sep 2024 16:25:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 923A18D025E; Wed, 4 Sep 2024 12:25:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8ADAC8D0253; Wed, 4 Sep 2024 12:25:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7282E8D025E; Wed, 4 Sep 2024 12:25:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 4D0EF8D0253 for ; Wed, 4 Sep 2024 12:25:14 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C16D74124A for ; Wed, 4 Sep 2024 16:25:13 +0000 (UTC) X-FDA: 82527580506.12.887B1C1 Received: from out-176.mta1.migadu.com (out-176.mta1.migadu.com [95.215.58.176]) by imf21.hostedemail.com (Postfix) with ESMTP id EC5501C0025 for ; Wed, 4 Sep 2024 16:25:11 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=qKrhGWgk; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf21.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.176 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725467034; a=rsa-sha256; cv=none; b=U4XiGvE8FCtcKUPz02GDqEmd4ctrayekX7felgTGWZnLqrOU47uUsPoy7f27ohNWl63tFH DqiWR/ZPw6NZUoPG2Mpkf5cHmkOUfJzJU8cX+qBq2C8p2X08Lp8UQA/9fnFBMSu8Wj/MzM vXtBkZ46jHWIwn/nMZWLl/lzbIXi6mM= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=qKrhGWgk; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf21.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.176 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725467034; 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=POkmkN/JwEJ0aZ0J8P8Ljm8OXcYXD7e6BRva/o/vMPo=; b=zPqxvI0IvelW1dNjwzNavnI/SVqt5PZPUpk6QLZTWQEEOdOXHt9O5CMwd12iR7qdy4QfVl Af2DOR2AjisqB2S63kmhuMlYYcaHchr98c+5Bx52KHMpmeeseapTfkiBQIN7ByHKQf2wJs zIypagP2aJ2BkXMLbMrg3W52dHKZw/E= Date: Wed, 4 Sep 2024 12:25:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1725467108; 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=POkmkN/JwEJ0aZ0J8P8Ljm8OXcYXD7e6BRva/o/vMPo=; b=qKrhGWgkIZu6+5ik7KWOzXV2F69wHv7gO/jlVAa3+Cs46uX7R2i1PHFBV2ZW2/R4qT8fBL ydkWpXJEDKp3KYYmPSYyGPM7lunMwDRchs+vtWYbHlY+Iyng1kZ/QfM9vd/j5snphs+CN4 +OTcYl0m8ZRJZSAJum+dlzPfUpUh4SU= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Suren Baghdasaryan Cc: 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, 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 5/6] alloc_tag: make page allocation tag reference size configurable Message-ID: References: <20240902044128.664075-1-surenb@google.com> <20240902044128.664075-6-surenb@google.com> <20240901220931.53d3ad335ae9ac3fe7ef3928@linux-foundation.org> <3kfgku2oxdcnqgtsevsc6digb2zyapbvchbcarrjipyxgytv2n@7tolozzacukf> 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: rspam12 X-Rspamd-Queue-Id: EC5501C0025 X-Stat-Signature: xd1np3kf55saggakhr9hpyiwyn5pod7p X-Rspam-User: X-HE-Tag: 1725467111-404716 X-HE-Meta: U2FsdGVkX1+nBn0y545XlMdil1R6gRrvXDaoc3Q5UP2v7loY3A+HQPJEXikPxjaO6JYm/fEOHSJmEYfumnn373ADhKcocyh0UwdqbqVFr9aHmhaaWhZ6MvC5VCC9PnUp2Pi0dE+pZITJOCYOBov367by2UgAcXYC5bp6ge6bfIR7Y4F3lRY+M0bAJuFVpapYItJoVXYRRHWAGnG8lmMUgZ5QbXB4A+bPsjWXMwrzoQpG6ILdZvPu6V5MGeiqPiofTHime1KxuXWaT+o/PUObGwrfpZZcrjQ7LJKDJ31kT8G3mcqGclxwK3mjBnZLEmK9cHeymw5/PAv/1X0sX+bfEi0bJdhtRmrvi2bk0P97bW0PF/IadHyn45EpC5pDA+ZzvZXXiOOwEXoTVcCdBXgemOWMSmBwVR23xTe+6md+BLLsJLghFOo9kWH5sSkD5s3xqkcgdBlYpcQO1DL2EN+2ZmGJ34sCcNE+cnG5Ap+y7gE44rgb83jPRG8TcSBYcj7l8B+IWnVyjEGO5EY3crEqIUsQRWeR9+s1BCEayzD681dH+mCjc9U2vq7qq7YSiiZhQp8gisq9+DWrm9MRz9VIej36GZKhP4ltwBcH3eSB4myzV7q/cpZ+xatHxi1j1ZOjhSJn7Gw67q5lChnKGUFUcVdWJSTCzc28BJ5xvD2tH0Xsu9vnRqKLRBzqlK685CYPi5h3BWccnD92QTCqw315OmMk3yotTBXlhK/kETxdsVEgBmZ3EHbWbcROvPLfs25+Xz6HvJ9aHxCT5hj73pmRjWRwFYJwmupgz//2CU5vM6JFo+Kv60WeP9CYJVTJIJPwHIMJEqiETt/v7Vd/ZtBvL6n2lqj+TbY2gwYb0vNp804qzkU3gZUS5IjnPKSnD5k6OlwHQOaiz8/Zwfge3jxABnYaWD1gH24NTn3kW3JS8a6d+5GnQf4bJ3zw8waJ0W/EgJbJUjRGpkSb9buNGYj Cc6wZsut is93oxXcrWTofbISpeIeZuu2adMri7XSMfsmUMdeavid+f/CVqt3E3KbyTx+0r+IFmH0Lu8I01jrZe4CkKjtkC8iWawRHgNhVfruZ9USfqpayXt6X9pGfHWXKHSUEBx4494yW/rS3c9hJcbJDAWs9XlhlnMmft41A5f7bEmOHHLeoWhabJlr/oQ25KDMr+VxJ6KZnGaTvjA52t+tG54xbiCFbk3Fyl1NsprrqwLSKxBqOUYDH9h78SKGL0Vap2PdzlHIwAB3SqEWpjcwYEZaI3nsxlIfXQhispCqwKEUPJQ7yxl9DZev9UUMStnRWy5Cx8bmkofychKfxK6aUgifKwbaon2nNSS/R8BNc 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 07:04:51PM GMT, Suren Baghdasaryan wrote: > On Tue, Sep 3, 2024 at 6:17 PM Kent Overstreet > wrote: > > > > On Tue, Sep 03, 2024 at 06:07:28PM GMT, Suren Baghdasaryan wrote: > > > On Sun, Sep 1, 2024 at 10:09 PM Andrew Morton wrote: > > > > > > > > On Sun, 1 Sep 2024 21:41:27 -0700 Suren Baghdasaryan wrote: > > > > > > > > > Introduce CONFIG_PGALLOC_TAG_REF_BITS to control the size of the > > > > > page allocation tag references. When the size is configured to be > > > > > less than a direct pointer, the tags are searched using an index > > > > > stored as the tag reference. > > > > > > > > > > ... > > > > > > > > > > +config PGALLOC_TAG_REF_BITS > > > > > + int "Number of bits for page allocation tag reference (10-64)" > > > > > + range 10 64 > > > > > + default "64" > > > > > + depends on MEM_ALLOC_PROFILING > > > > > + help > > > > > + Number of bits used to encode a page allocation tag reference. > > > > > + > > > > > + Smaller number results in less memory overhead but limits the number of > > > > > + allocations which can be tagged (including allocations from modules). > > > > > + > > > > > > > > In other words, "we have no idea what's best for you, you're on your > > > > own". > > > > > > > > I pity our poor users. > > > > > > > > Can we at least tell them what they should look at to determine whether > > > > whatever random number they chose was helpful or harmful? > > > > > > At the end of my reply in > > > https://lore.kernel.org/all/CAJuCfpGNYgx0GW4suHRzmxVH28RGRnFBvFC6WO+F8BD4HDqxXA@mail.gmail.com/#t > > > I suggested using all unused page flags. That would simplify things > > > for the user at the expense of potentially using more memory than we > > > need. > > > > Why would that use more memory, and how much? > > Say our kernel uses 5000 page allocations and there are additional 100 > allocations from all the modules we are loading at runtime. They all > can be addressed using 13 bits (8192 addressable tags), so the > contiguous memory we will be preallocating to store these tags is 8192 > * sizeof(alloc_tag). sizeof(alloc_tag) is 40 bytes as of today but > might increase in the future if we add more fields there for other > uses (like gfp_flags for example). So, currently this would use 320KB. > If we always use 16 bits we would be preallocating 2.5MB. So, that > would be 2.2MB of wasted memory. Using more than 16 bits (65536 > addressable tags) will be impractical anytime soon (current number > IIRC is a bit over 4000). I see, it's not about the page bits, it's about the contiguous array of alloc tags? What if we just reserved address space, and only filled it in as needed?