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 ACC31CD37BB for ; Wed, 4 Sep 2024 01:17:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 29EB68D0209; Tue, 3 Sep 2024 21:17:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24CD68D018A; Tue, 3 Sep 2024 21:17:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0EDE48D0209; Tue, 3 Sep 2024 21:17:06 -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 E567D8D018A for ; Tue, 3 Sep 2024 21:17:05 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 98FD3140BD2 for ; Wed, 4 Sep 2024 01:17:05 +0000 (UTC) X-FDA: 82525292010.09.2BDD58E Received: from out-176.mta1.migadu.com (out-176.mta1.migadu.com [95.215.58.176]) by imf01.hostedemail.com (Postfix) with ESMTP id 91A4C40008 for ; Wed, 4 Sep 2024 01:17:03 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=gtEuMQcK; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf01.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=1725412546; a=rsa-sha256; cv=none; b=Aldb8KnemEdx3EepTMqVDqVxU+06iKLNAipMwKZ3w3hVKLLcdZB/NTVQsa3qaOuPLU8K7z a4BCn6eyO/sSHFoizOr/KuivlXVODmz/XTu1S9uVHdy3cTUCGwD1bcCXILTPm+2UV5fC/B 3tIisdliWE10X2RsKsFgcg+MhFheIt0= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=gtEuMQcK; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf01.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=1725412546; 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=rQzYOHMyrq7t59Ykk0pAhpV7+DRQum6wY5MPwnLcic4=; b=t3c5/asQfSHnKGS8vUm057FGliu9zhSCxkMn5c58VrNn7MF3jucT2m/TmPHrp1hoWfqdbw CGtqisCpWzJ+HyZQUzZjJniPmkEdU/M+R8gj9fplQru6HOoEvGIU5D4ebiJ6QLmJTxTYyu Rm1er1jSJXLY5812xL1kudtj1h0I+iE= Date: Tue, 3 Sep 2024 21:16:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1725412620; 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=rQzYOHMyrq7t59Ykk0pAhpV7+DRQum6wY5MPwnLcic4=; b=gtEuMQcK45L8judrF5ka80VaQCtIaWgD5a4OzH+xUHPET9XKz83gNn6GCOX84C3e3mq9rO rFUei0M4L39R6xeJMY9/20AMzJI2jfbIssaZzgOqbDOOA3j0zhD24smbPjgXriKR3CNOYf wUpxTIhmvpLv9a8ZrpbX+9sIt7jDXqo= 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: <3kfgku2oxdcnqgtsevsc6digb2zyapbvchbcarrjipyxgytv2n@7tolozzacukf> References: <20240902044128.664075-1-surenb@google.com> <20240902044128.664075-6-surenb@google.com> <20240901220931.53d3ad335ae9ac3fe7ef3928@linux-foundation.org> 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: 91A4C40008 X-Stat-Signature: ukotq5onnrtu84x4zujii31fwj9g6p5h X-Rspam-User: X-HE-Tag: 1725412623-206952 X-HE-Meta: U2FsdGVkX1+l13fii6ECogadhsfXFEiDPQGFP0upkxJnAyt4lZFje1xbpBCZri/8lhTgcCRWSp9jw9GYRbR+e7fNmG2MonETrcFbk+i8cxv2INV3YATi8JJDR2AXWeiPeUh1FdqIz6nqUE0BFn9LVpKOUNWnW3UIL3Zjydh4deo0WLjM+G17eZqin569ULcy6qHH+nC6MEtoq4Sb+DicFN9QiFL3rF6FFqA5ng+jDC+6qv/nRsDxvKn9iPtGfAueE7eeCieIMMRjp3bdzv3fYg+t0p8GGiKwKikkPK2rM6df4LPPrfQ1swEU6MQfUv89phR5/afVz0FG6nNYgxzfBqCmJknpAz4ylggik4TlUI3axuFAYMrnlknghGakI4haXaKS6enNosRD/tYF1Nr5y3P1En1jX9nOTJadwzbzF13T5q5iCdfbWEMOnisLLgGqg4zAZwWBirmDDEmJCwPRp0HA1jjscubwR0886DmgvMgKVmfd/hr61kNjRttXU17KZCIf0JGyk3BCsszPxWEUEhjGOxmi3EJaAA/wkbiw6zPZ75NAWhOAtZE4Qs3xjl2Im9Wuzw0xolt0gIUMpl7Ul2wBFpqjc1R5dESx0tEyARsUp477pdqgc+duqGbElEb7tQMkw9MGF5wuY8dlBPYEtIwJcHyhcP6Oe7V0hLIpfWub4YTJBm7pZ8xzpLySvttZ9IpGoOGoWIv3N3Kn0UtoTyGnWGfiNi2DSCXwfzxEelvx0TJ9YUzotYyTR1EIKuxlDyE7wPJ8m9x1rntxk/StagC9WK1v37GcW5CPYzdfgQH3kEgCYT6D5J0uSM8l3apRxTaEIQPHyI8lYkKaJyyrS0r5P0zJtbWWkEnXwZ8hERRY/cjdSupwNNJ/xthMiv/OS7djWZckZVuFUc2DPQi4lfGG0IIci45V673oVDVGOWunxoP5J5waZCMGH8Il8ebkwo5rDizMQ0VcjWADlDt 3ZIxhMJn 9CLaD+YGcLU7Kr7JTOBkI6o0xFAG6LdSmwSJy+ylB608XuNiAcTagFZN5jAKJ15grab0h8CH/fz7Kkn6cOBEDrm29LWGf8WmLU/9xtn2N1mQOzY5lbdjhjLJnvjQ5CTIEK93DrYkJWj1F166wM0Ls5lNT3RIPSqaSgSUlsINmp/xXBm5hMlxL8nr5p+CY5qet3VQxBcVmsNEwUg8gQfkOOfNgD/JKQLSpX1ijUxv6nog4pI8jqQLJvullIsLRk4J5r8Ss5Cyd73bzDg7SAxJG97BUQXfM6tM866ilcwC8K+Wbu+OrXv4WDdzqBuUVP86jvWk6LdY63hSAC/XdhQakQVaOlP+a0Uqv6DRL 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: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? > In practice 13 bits should be more than enough to cover all > kernel page allocations with enough headroom for page allocations > coming from loadable modules. I guess using 13 as the default would > cover most cases. In the unlikely case a specific system needs more > tags, the user can increase this value. It can also be set to 64 to > force direct references instead of indexing for better performance. > Would that approach be acceptable? Any knob that has to be kept track of and adjusted is a real hassle - e.g. lockdep has a bunch of knobs that have to be periodically tweaked, that's used by _developers_, and they're often wrong.