linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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,




  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).