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 19:05:52 -0700 [thread overview]
Message-ID: <70ef75d9-a573-4989-9a9d-c8bc087f212b@nvidia.com> (raw)
In-Reply-To: <47c4ef47-3948-4e46-8ea5-6af747293b18@nvidia.com>
On 9/3/24 6:25 PM, John Hubbard wrote:
> 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
I should probably clarify my previous reply, so here is the more detailed
version:
>> 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
Yes.
>> 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.
The configuration should disable itself, in this case. But if that is
too big of a change for now, I suppose we could fall back to an error
message to the effect of, "please disable CONFIG_PGALLOC_TAG_USE_PAGEFLAGS
because the kernel build system is still too primitive to do that for you". :)
>> - 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.
Let's try to decide now, what that tradeoff should be. Just pick one based
on what some of us perceive to be the expected usefulness and frequency of
use between last_cpuid and these tag refs.
If someone really needs to change the tradeoff for that one bit, then that
someone is also likely able to hack up a change for it.
thanks,
--
John Hubbard
>> - 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,
next prev parent reply other threads:[~2024-09-04 2:06 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
2024-09-04 2:05 ` John Hubbard [this message]
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=70ef75d9-a573-4989-9a9d-c8bc087f212b@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;
as well as URLs for NNTP newsgroup(s).