From: "Vishal Moola (Oracle)" <vishal.moola@gmail.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] mm: tag kernel stack pages
Date: Fri, 5 Sep 2025 10:47:38 -0700 [thread overview]
Message-ID: <aLsiOvvxhJnTzKO6@fedora> (raw)
In-Reply-To: <84297d37-b766-4cfe-9c3f-bff1cb3cb4a4@redhat.com>
On Thu, Sep 04, 2025 at 12:23:31PM +0200, David Hildenbrand wrote:
> On 03.09.25 20:19, Vishal Moola (Oracle) wrote:
> > On Wed, Sep 03, 2025 at 09:49:06AM +0200, David Hildenbrand wrote:
> > > [resending my original mail because it might have landed in the spam folder]
> >
> > Ah, indeed the original mail was found in my spam folder. Thanks for
> > resending.
> >
> > > On 20.08.25 22:20, Vishal Moola (Oracle) wrote:
> > > > Currently, we have no way to distinguish a kernel stack page from an
> > > > unidentified page. Being able to track this information can be
> > > > beneficial for optimizing kernel memory usage (i.e. analyzing
> > > > fragmentation, location etc.). Knowing a page is being used for a kernel
> > > > stack gives us more insight about pages that are certainly immovable and
> > > > important to kernel functionality.
> > >
> > > It's a very niche use case. Anything that's not clearly a folio or a
> > > special movable_ops page is certainly immovable. So we can identify
> > > pretty reliable what's movable and what's not.
> > >
> > > Happy to learn how you would want to use that knowledge to reduce
> > > fragmentation. 🙂
> > >
> > > So this reads a bit hand-wavy.
> >
> > My thoughts align with Matthew's response. If we decide "This doesn't add
> > enough value to merge it upstream" thats fine by me.
> >
> > Otherwise if we think this is useful, I can respin this with your
> > suggestion below.
>
> As raised in my other mail, I assume there is no way to just have any stack
> pages in any kernel config marked appropriately (slab allocation
> discussion)?
>
> If so, I prefer to not add it.
I agree, this shouldn't be tied to specific kernel configs. We can leave this
out of tree.
I didn't know a page could only have one type, and trying to handle that
doesn't help explore what we're interested in right now anyway.
> If there is a way to just make it consistent, then no strong opinion from my
> side. Willy is the page-type guard :)
>
> BTW, I was wondering if page-owner could be useful instead.
Thanks for the suggestion, page-owner looks useful for playing around with
different kernel stack allocation methods :)
> --
> Cheers
>
> David / dhildenb
>
prev parent reply other threads:[~2025-09-05 17:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-20 20:20 [PATCH] mm: tag kernel stack pages Vishal Moola (Oracle)
2025-08-21 12:44 ` David Hildenbrand
2025-09-02 19:52 ` Matthew Wilcox
2025-09-04 10:31 ` David Hildenbrand
2025-09-03 7:49 ` David Hildenbrand
2025-09-03 18:19 ` Vishal Moola (Oracle)
2025-09-04 10:23 ` David Hildenbrand
2025-09-05 17:47 ` Vishal Moola (Oracle) [this message]
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=aLsiOvvxhJnTzKO6@fedora \
--to=vishal.moola@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.