Re: linux-next: manual merge of the mm-unstable tree with the drm-misc-fixes tree

[Matthew Brost <matthew.brost@intel.com>]

On Mon, Jul 20, 2026 at 03:08:22PM -0700, Matthew Brost wrote:
> On Mon, Jul 20, 2026 at 03:46:00PM +0100, Matthew Wilcox wrote:
> > On Mon, Jul 20, 2026 at 04:41:41PM +0200, Christoph Hellwig wrote:
> > > >   /**
> > > >  - * ttm_backup_backup_page() - Backup a page
> > > >  + * ttm_backup_backup_folio() - Backup a folio
> > > >    * @backup: The struct backup pointer to use.
> > > >  - * @page: The page to back up.
> > > >  - * @writeback: Whether to perform immediate writeback of the page.
> > > >  + * @folio: The folio to back up.
> > > >  + * @order: The allocation order of @folio.  Since TTM allocates higher-order
> > > >  + *         pages without __GFP_COMP, folio_nr_pages(@folio) would always
> > > >  + *         return 1; the caller must pass the true order explicitly.
> > 
> > Wait, what?  This is just broken.  TTM should change to allocate using
> > GFP_COMP.  Why can't graphics people ask questions before writing stupid
> > patches?
> > 
> 
> To be honest, I have no idea why TTM doesn't set GFP_COMP. This
> predates my work in graphics by nearly a decade.
> 
> I found the following comment in TTM, which was added in this patch:
> `git format-patch -1 bf9eee249ac20`
> 
> As far as I can tell, setting GFP_COMP would make things a lot easier in
> a number of places.
> 
> Christian, who maintains TTM, is out for a couple of weeks, but this is
> something we should probably take a closer look at.
> 

I have looked into this a bit, changing TTM over to allocations with
GFP_COMP seems pretty straight forward. I have local patches that are
working with my driver (Xe), will post something shortly.

Matt

> Sorry for sending a stupid patch.
> 
> Matt