From: Andrew Morton <akpm@linux-foundation.org>
To: Suren Baghdasaryan <surenb@google.com>
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
Date: Sun, 1 Sep 2024 22:16:36 -0700 [thread overview]
Message-ID: <20240901221636.5b0af3694510482e9d9e67df@linux-foundation.org> (raw)
In-Reply-To: <20240902044128.664075-7-surenb@google.com>
On Sun, 1 Sep 2024 21:41:28 -0700 Suren Baghdasaryan <surenb@google.com> 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?
next prev parent reply other threads:[~2024-09-02 5:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-02 4:41 [PATCH v2 0/6] page allocation tag compression Suren Baghdasaryan
2024-09-02 4:41 ` [PATCH v2 1/6] maple_tree: add mas_for_each_rev() helper Suren Baghdasaryan
2024-09-02 4:41 ` [PATCH v2 2/6] alloc_tag: load module tags into separate continuous memory Suren Baghdasaryan
2024-09-02 4:41 ` [PATCH v2 3/6] alloc_tag: eliminate alloc_tag_ref_set Suren Baghdasaryan
2024-09-02 4:41 ` [PATCH v2 4/6] alloc_tag: introduce pgalloc_tag_ref to abstract page tag references Suren Baghdasaryan
2024-09-02 4:41 ` [PATCH v2 5/6] alloc_tag: make page allocation tag reference size configurable Suren Baghdasaryan
2024-09-02 5:09 ` Andrew Morton
2024-09-04 1:07 ` Suren Baghdasaryan
2024-09-04 1:16 ` Kent Overstreet
2024-09-04 2:04 ` Suren Baghdasaryan
2024-09-04 16:25 ` Kent Overstreet
2024-09-04 16:35 ` Suren Baghdasaryan
2024-09-02 4:41 ` [PATCH v2 6/6] alloc_tag: config to store page allocation tag refs in page flags Suren Baghdasaryan
2024-09-02 5:16 ` Andrew Morton [this message]
2024-09-03 18:19 ` Suren Baghdasaryan
2024-09-04 1:25 ` John Hubbard
2024-09-04 2:05 ` John Hubbard
2024-09-04 16:08 ` Suren Baghdasaryan
2024-09-04 18:58 ` John Hubbard
2024-09-04 21:07 ` Suren Baghdasaryan
2024-09-04 2:18 ` Matthew Wilcox
2024-09-04 16:18 ` Suren Baghdasaryan
2024-09-04 16:21 ` Kent Overstreet
2024-09-04 16:35 ` Matthew Wilcox
2024-09-04 16:37 ` Kent Overstreet
2024-09-04 16:39 ` Suren Baghdasaryan
2024-09-04 2:41 ` Kent Overstreet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240901221636.5b0af3694510482e9d9e67df@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave@stgolabs.net \
--cc=david@redhat.com \
--cc=dennis@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=jhubbard@nvidia.com \
--cc=kaleshsingh@google.com \
--cc=keescook@chromium.org \
--cc=kent.overstreet@linux.dev \
--cc=kernel-team@android.com \
--cc=liam.howlett@oracle.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=mhocko@suse.com \
--cc=minchan@google.com \
--cc=pasha.tatashin@soleen.com \
--cc=paulmck@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=souravpanda@google.com \
--cc=surenb@google.com \
--cc=tglx@linutronix.de \
--cc=thuth@redhat.com \
--cc=vbabka@suse.cz \
--cc=vvvvvv@google.com \
--cc=willy@infradead.org \
--cc=xiongwei.song@windriver.com \
--cc=yuzhao@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox