From: John Hubbard <jhubbard@nvidia.com>
To: Suren Baghdasaryan <surenb@google.com>,
Andrew Morton <akpm@linux-foundation.org>
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>, <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: Tue, 3 Sep 2024 18:25:52 -0700 [thread overview]
Message-ID: <47c4ef47-3948-4e46-8ea5-6af747293b18@nvidia.com> (raw)
In-Reply-To: <CAJuCfpGNYgx0GW4suHRzmxVH28RGRnFBvFC6WO+F8BD4HDqxXA@mail.gmail.com>
On 9/3/24 11:19 AM, Suren Baghdasaryan wrote:
> On Sun, Sep 1, 2024 at 10:16 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>> On Sun, 1 Sep 2024 21:41:28 -0700 Suren Baghdasaryan <surenb@google.com> wrote:
...
>> We shouldn't be offering things like this to our users. If we cannot decide, how
>> can they?
>
> Thinking about the ease of use, the CONFIG_PGALLOC_TAG_REF_BITS is the
> hardest one to set. The user does not know how many page allocations
> are there. I think I can simplify this by trying to use all unused
> page flag bits for addressing the tags. Then, after compilation we can
> follow the rules I mentioned before:
> - If the available bits are not enough to address all kernel page
> allocations, we issue an error. The user should disable
> CONFIG_PGALLOC_TAG_USE_PAGEFLAGS.
> - If there are enough unused bits but we have to push last_cpupid out
> of page flags, we issue a warning and continue. The user can disable
> CONFIG_PGALLOC_TAG_USE_PAGEFLAGS if last_cpupid has to stay in page
> flags.
> - If we run out of addressing space during module loading, we disable
> allocation tagging and continue. The user should disable
> CONFIG_PGALLOC_TAG_USE_PAGEFLAGS.
If the computer already knows what to do, it should do it, rather than
prompting the user to disable a deeply mystifying config parameter.
>
> This leaves one outstanding case:
> - If we run out of addressing space during module loading but we would
> not run out of space if we pushed last_cpupid out of page flags during
> compilation.
> In this case I would want the user to have an option to request a
> larger addressing space for page allocation tags at compile time.
> Maybe I can keep CONFIG_PGALLOC_TAG_REF_BITS for such explicit
> requests for a larger space? This would limit the use of
> CONFIG_PGALLOC_TAG_REF_BITS to this case only. In all other cases the
> number of bits would be set automatically. WDYT?
Manually dealing with something like this is just not going to work.
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.
thanks,
--
John Hubbard
NVIDIA
next prev parent reply other threads:[~2024-09-04 1:26 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
2024-09-03 18:19 ` Suren Baghdasaryan
2024-09-04 1:25 ` John Hubbard [this message]
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=47c4ef47-3948-4e46-8ea5-6af747293b18@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=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=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