linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: John Hubbard <jhubbard@nvidia.com>,
	Yosry Ahmed <yosryahmed@google.com>,
	Suren Baghdasaryan <surenb@google.com>
Cc: akpm@linux-foundation.org, 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, 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 v3 5/5] alloc_tag: config to store page allocation tag refs in page flags
Date: Tue, 15 Oct 2024 09:32:01 +0200	[thread overview]
Message-ID: <6a2a84f5-8474-432f-b97e-18552a9d993c@redhat.com> (raw)
In-Reply-To: <cd848c5f-50cd-4834-a6dc-dff16c586e49@nvidia.com>

On 15.10.24 01:53, John Hubbard wrote:
> On 10/14/24 4:48 PM, Yosry Ahmed wrote:
>> On Mon, Oct 14, 2024 at 1:37 PM Suren Baghdasaryan <surenb@google.com> wrote:
>>>
>>> Add CONFIG_PGALLOC_TAG_USE_PAGEFLAGS to store allocation tag
>>> references directly in the page flags. This eliminates memory
>>> overhead caused by page_ext and results in better performance
>>> for page allocations.
>>> If the number of available page flag bits is insufficient to
>>> address all kernel allocations, profiling falls back to using
>>> page extensions with an appropriate warning to disable this
>>> config.
>>> If dynamically loaded modules add enough tags that they can't
>>> be addressed anymore with available page flag bits, memory
>>> profiling gets disabled and a warning is issued.
>>
>> Just curious, why do we need a config option? If there are enough bits
>> in page flags, why not use them automatically or fallback to page_ext
>> otherwise?
> 
> Or better yet, *always* fall back to page_ext, thus leaving the
> scarce and valuable page flags available for other features?
> 
> Sorry Suren, to keep coming back to this suggestion, I know
> I'm driving you crazy here! But I just keep thinking it through
> and failing to see why this feature deserves to consume so
> many page flags.

My 2 cents: there is nothing wrong about consuming unused page flags in 
a configuration. No need to let them stay unused in a configuration :)

The real issue starts once another feature wants to make use of some of 
them ... in such configuration there would be less available for 
allocation tags and the performance of allocations tags might 
consequently get worse again.

-- 
Cheers,

David / dhildenb



  parent reply	other threads:[~2024-10-15  7:32 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-14 20:36 [PATCH v3 0/5] page allocation tag compression Suren Baghdasaryan
2024-10-14 20:36 ` [PATCH v3 1/5] maple_tree: add mas_for_each_rev() helper Suren Baghdasaryan
2024-10-16  1:48   ` Liam R. Howlett
2024-10-16  5:33     ` Suren Baghdasaryan
2024-10-14 20:36 ` [PATCH v3 2/5] alloc_tag: load module tags into separate contiguous memory Suren Baghdasaryan
2024-10-14 23:51   ` Andrew Morton
2024-10-15  2:10     ` Suren Baghdasaryan
2024-10-15 21:08       ` Shakeel Butt
2024-10-15 22:59         ` Suren Baghdasaryan
2024-10-14 20:36 ` [PATCH v3 3/5] alloc_tag: populate memory for module tags as needed Suren Baghdasaryan
2024-10-15 12:15   ` Mike Rapoport
2024-10-15 14:49     ` Suren Baghdasaryan
2024-10-14 20:36 ` [PATCH v3 4/5] alloc_tag: introduce pgalloc_tag_ref to abstract page tag references Suren Baghdasaryan
2024-10-14 20:36 ` [PATCH v3 5/5] alloc_tag: config to store page allocation tag refs in page flags Suren Baghdasaryan
2024-10-14 23:48   ` Yosry Ahmed
2024-10-14 23:53     ` John Hubbard
2024-10-14 23:56       ` Yosry Ahmed
2024-10-15  0:03         ` John Hubbard
2024-10-15  1:40           ` Matthew Wilcox
2024-10-15  2:03             ` Suren Baghdasaryan
2024-10-15  1:58           ` Suren Baghdasaryan
2024-10-15  8:10             ` Yosry Ahmed
2024-10-15 15:06               ` Suren Baghdasaryan
2024-10-15  7:32       ` David Hildenbrand [this message]
2024-10-15 14:59         ` Suren Baghdasaryan
2024-10-15 15:42           ` David Hildenbrand
2024-10-15 15:58             ` Suren Baghdasaryan
2024-10-18 13:03               ` Michal Hocko
2024-10-18 16:04                 ` Suren Baghdasaryan
2024-10-18 17:08                   ` Michal Hocko
2024-10-18 17:45                     ` Suren Baghdasaryan
2024-10-18 21:57                       ` Suren Baghdasaryan
2024-10-21  7:26                         ` Michal Hocko
2024-10-21  9:13                           ` David Hildenbrand
2024-10-21 15:05                             ` Suren Baghdasaryan
2024-10-21 15:34                               ` Michal Hocko
2024-10-21 15:41                                 ` Suren Baghdasaryan
2024-10-21 15:49                                   ` David Hildenbrand
2024-10-21 15:57                                   ` Michal Hocko
2024-10-21 16:16                                     ` Suren Baghdasaryan
2024-10-21 16:23                                       ` Michal Hocko
2024-10-21 16:32                                         ` Suren Baghdasaryan
2024-10-21 18:12                                           ` John Hubbard
2024-10-21  7:21                       ` Michal Hocko
2024-10-14 23:32 ` [PATCH v3 0/5] page allocation tag compression Andrew Morton
2024-10-15  1:48   ` Suren Baghdasaryan
2024-10-15 16:26     ` Suren Baghdasaryan

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=6a2a84f5-8474-432f-b97e-18552a9d993c@redhat.com \
    --to=david@redhat.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=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=yosryahmed@google.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).