On 2018-05-02 06:21 PM, Christoph Hellwig wrote: > On Wed, May 02, 2018 at 04:31:09PM +0200, Michel Dänzer wrote: >>> No. __GFP_NOWARN (and gfp_t flags in general) are the wrong interface >>> for dma allocations and just cause problems. I actually plan to >>> get rid of the gfp_t argument in dma_alloc_attrs sooner, and only >>> allow either GFP_KERNEL or GFP_DMA passed in dma_alloc_coherent. >> >> How about GFP_TRANSHUGE_LIGHT? TTM uses that to opportunistically >> allocate huge pages (GFP_TRANSHUGE can result in unacceptably long >> delays with memory pressure). > > Well, that is exactly what I don't want drivers to do - same for > __GFP_COMP in some drm code. This very much assumes the page allocator > is used to back dma allocations, which very often it actually isn't, and > any use of magic gfp flags creates a tight coupling of consumers with a > specific implementation. > > In general I can't think of a good reason not to actually use > GFP_TRANSHUGE_LIGHT by default in the dma allocator unless > DMA_ATTR_ALLOC_SINGLE_PAGES is set. Can you prepare a patch for that? I'm afraid I'll have to leave that to somebody else. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
