All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: "Cédric Le Goater" <clg@redhat.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	linux-mm@kvack.org, "Peter Xu" <peterx@redhat.com>,
	"David Hildenbrand" <david@kernel.org>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Jason Gunthorpe" <jgg@nvidia.com>, "Zi Yan" <ziy@nvidia.com>,
	stable@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check
Date: Thu, 6 Aug 2026 07:29:15 +0100	[thread overview]
Message-ID: <anQpWs6fapNVZSdt@lucifer> (raw)
In-Reply-To: <anPm6vGNeDxLFIkJ@casper.infradead.org>

On Thu, Aug 06, 2026 at 02:44:10AM +0100, Matthew Wilcox wrote:
> On Wed, Aug 05, 2026 at 11:41:46AM +0100, Lorenzo Stoakes (ARM) wrote:
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index abc65d608c23..5fa01364f089 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -111,6 +111,34 @@ static bool vma_is_special_huge(const struct vm_area_struct *vma)
> >  	return vma_test_any(vma, VMA_PFNMAP_BIT, VMA_MIXEDMAP_BIT);
> >  }
> >
> > +static bool should_obey_thp_file_tunables(const struct vm_area_struct *vma,
> > +					  bool forced_collapse)
> > +{
> > +	if (forced_collapse)
> > +		return false;
> > +	VM_WARN_ON_ONCE(vma_is_anonymous(vma));
> > +	/* Huge PFN mappings allocate no folios so the policy doesn't apply. */
> > +	if (vma_test(vma, VMA_PFNMAP_BIT) && vma->vm_ops->huge_fault)
> > +		return false;
> > +	return true;
> > +}
> > +
> > +static bool can_thp_collapse_file(const struct vm_area_struct *vma,
> > +		vm_flags_t vm_flags, bool forced_collapse)
> > +{
> > +	/* Override THP tunables? */
> > +	if (!should_obey_thp_file_tunables(vma, forced_collapse))
> > +		return true;
> > +	/* THP=always? */
> > +	if (hugepage_global_always())
> > +		return true;
> > +	/* THP=madvise? */
> > +	if (!hugepage_global_enabled())
> > +		return false;
> > +	/* Has VMA had madvise(..., MADV_HUGEPAGE) applied to it? */
> > +	return vm_flags & VM_HUGEPAGE;
> > +}
> > +
> >  unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
> >  					 vm_flags_t vm_flags,
> >  					 enum tva_type type,
> > @@ -188,9 +216,7 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
> >  		 * Enforce THP collapse requirements as necessary. Anonymous vmas
> >  		 * were already handled in thp_vma_allowable_orders().
> >  		 */
> > -		if (!forced_collapse &&
> > -		    (!hugepage_global_enabled() || (!(vm_flags & VM_HUGEPAGE) &&
> > -						    !hugepage_global_always())))
> > +		if (!can_thp_collapse_file(vma, vm_flags, forced_collapse))
> >  			return 0;
> >
> >  		/*
>
> I think 'thp_' in all of this is confusing.  DAX isn't THPs.  PFNMAPs
> aren't THPa.  There's other reasons to implement huge_fault that aren't
> THPs.  Can we rename all of this to drop the 'thp_' string, starting
> with thp_vma_allowable_order()?

Matthew, are you baiting the churnmeister 3000 into a refactor here? :)

I despise this function and agree with you entirely.

So maybe I could add a few other patches first before the change to improve
the horror show that is this function and its auxiliaries also :)

--
Cheers, Lorenzo


  reply	other threads:[~2026-08-06  6:29 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-05  5:55 [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check Cédric Le Goater
2026-08-05 10:41 ` Lorenzo Stoakes (ARM)
2026-08-05 16:21   ` Cédric Le Goater
2026-08-05 16:26     ` Lorenzo Stoakes (ARM)
2026-08-05 16:29       ` Cédric Le Goater
2026-08-06  1:44   ` Matthew Wilcox
2026-08-06  6:29     ` Lorenzo Stoakes (ARM) [this message]
2026-08-06 16:19   ` David Hildenbrand (Arm)
2026-08-06 16:34     ` Cédric Le Goater
2026-08-06 16:45       ` David Hildenbrand (Arm)
2026-08-05 12:15 ` Jason Gunthorpe
2026-08-05 16:29   ` Lorenzo Stoakes (ARM)
2026-08-05 16:52     ` Jason Gunthorpe
2026-08-05 16:54       ` Lorenzo Stoakes (ARM)
2026-08-06 14:26 ` David Hildenbrand (Arm)
2026-08-06 14:28   ` Lorenzo Stoakes (ARM)
2026-08-06 14:42     ` Cédric Le Goater
2026-08-06 14:47       ` David Hildenbrand (Arm)
2026-08-06 14:53         ` Cédric Le Goater
2026-08-06 14:59           ` David Hildenbrand (Arm)
2026-08-06 16:45         ` Jason Gunthorpe
2026-08-06 16:47           ` David Hildenbrand (Arm)
2026-08-06 16:50           ` AI slop (was Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP) " Lorenzo Stoakes (ARM)
2026-08-06 17:05             ` John Hubbard
2026-08-06 17:08               ` Zi Yan
2026-08-06 17:40                 ` Gregory Price
2026-08-06 17:42                   ` Lorenzo Stoakes (ARM)
2026-08-06 19:28                     ` Gregory Price
2026-08-06 19:33                       ` Lorenzo Stoakes (ARM)
2026-08-06 17:42                   ` Zi Yan
2026-08-06 17:41                 ` Lorenzo Stoakes (ARM)

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=anQpWs6fapNVZSdt@lucifer \
    --to=ljs@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alex.williamson@redhat.com \
    --cc=clg@redhat.com \
    --cc=david@kernel.org \
    --cc=jgg@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=willy@infradead.org \
    --cc=ziy@nvidia.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 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.