linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Shakeel Butt <shakeel.butt@linux.dev>
To: Matthew Wilcox <willy@infradead.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	 Andrew Morton <akpm@linux-foundation.org>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	 David Hildenbrand <david@redhat.com>,
	Vlastimil Babka <vbabka@suse.cz>, Jann Horn <jannh@google.com>,
	 Arnd Bergmann <arnd@arndb.de>,
	Christian Brauner <brauner@kernel.org>,
	 SeongJae Park <sj@kernel.org>,
	Usama Arif <usamaarif642@gmail.com>,
	 Mike Rapoport <rppt@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	 Barry Song <21cnbao@gmail.com>,
	linux-mm@kvack.org, linux-arch@vger.kernel.org,
	 linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	Pedro Falcato <pfalcato@suse.de>
Subject: Re: [DISCUSSION] proposed mctl() API
Date: Thu, 29 May 2025 10:54:34 -0700	[thread overview]
Message-ID: <c7fqqny5yv7smhxnxe5o4rc2wepmc6uei76teymfhxoana34nk@sfqnc2qclf23> (raw)
In-Reply-To: <aDh9LtSLCiTLjg2X@casper.infradead.org>

Hi Willy,

On Thu, May 29, 2025 at 04:28:46PM +0100, Matthew Wilcox wrote:
> On Thu, May 29, 2025 at 03:43:26PM +0100, Lorenzo Stoakes wrote:
> > After discussions in various threads (Usama's series adding a new prctl()
> > in [0], and a proposal to adapt process_madvise() to do the same -
> > conception in [1] and RFC in [2]), it seems fairly clear that it would make
> > sense to explore a dedicated API to explicitly allow for actions which
> > affect the virtual address space as a whole.
> > 
> > Also, Barry is implementing a feature (currently under RFC) which could
> > additionally make use of this API (see [3]).
> 
> I think the reason that you're having trouble coming up with a good
> place to put these ideas is because they are all bad ideas.  Do none of
> them.  Problem solved.
> 
> People should put more effort into allocating THPs automatically and
> monitoring where they're helping performance and where they're hurting
> performance,

Can you please expand on people putting more effort? Is it about
workloads or maybe malloc implementations (tcmalloc, jemalloc) being
more intelligent in managing their allocations/frees to keep more used
memory in hugepage aligned regions? And conveying to kernel which
regions they prefer hugepage backed and which they do not? Or something
else?

> instead of coming up with these baroque reasons to blame
> the sysadmin for not having tweaked some magic knob.

To me this is not about blaming sysadmin but more about sysadmin wanting
more fine grained control on THP allocation policies for different
workloads running in a multi-tenant environment.


  reply	other threads:[~2025-05-29 17:54 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-29 14:43 Lorenzo Stoakes
2025-05-29 15:28 ` Matthew Wilcox
2025-05-29 17:54   ` Shakeel Butt [this message]
2025-05-29 18:13     ` Matthew Wilcox
2025-05-29 18:32       ` Usama Arif
2025-05-29 21:14   ` Johannes Weiner
2025-05-29 21:24     ` Liam R. Howlett
2025-05-29 23:14       ` Johannes Weiner
2025-05-30  7:52     ` Barry Song
2025-06-04 12:00       ` Johannes Weiner
2025-06-04 12:05         ` David Hildenbrand
2025-05-30 10:31     ` Vlastimil Babka
2025-06-04 12:19       ` Johannes Weiner
2025-06-05 12:31         ` Johannes Weiner
2025-06-09 17:03           ` Tejun Heo
2025-06-02 18:01     ` Matthew Wilcox
2025-06-04 13:21       ` Johannes Weiner
2025-06-04 12:28   ` Lorenzo Stoakes
2025-05-29 17:21 ` Usama Arif
2025-05-30 13:10   ` Lorenzo Stoakes
2025-06-10 15:03     ` Usama Arif
2025-06-10 15:17       ` Lorenzo Stoakes
2025-06-10 15:30         ` Usama Arif
2025-06-10 15:46           ` Matthew Wilcox
2025-06-10 16:00             ` Usama Arif
2025-06-10 16:26               ` Matthew Wilcox
2025-06-10 17:02                 ` Usama Arif
2025-06-10 16:02           ` Lorenzo Stoakes
2025-07-02 14:15           ` Usama Arif
2025-07-02 17:38             ` SeongJae Park
2025-07-04 10:34               ` David Hildenbrand
2025-05-29 18:50 ` Andy Lutomirski
2025-05-29 21:31 ` Andrew Morton

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=c7fqqny5yv7smhxnxe5o4rc2wepmc6uei76teymfhxoana34nk@sfqnc2qclf23 \
    --to=shakeel.butt@linux.dev \
    --cc=21cnbao@gmail.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=brauner@kernel.org \
    --cc=david@redhat.com \
    --cc=hannes@cmpxchg.org \
    --cc=jannh@google.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=pfalcato@suse.de \
    --cc=rppt@kernel.org \
    --cc=sj@kernel.org \
    --cc=usamaarif642@gmail.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /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