On Thu, 2020-11-19 at 10:38 +0100, Michal Hocko wrote: > On Fri 13-11-20 22:40:40, Rik van Riel wrote: > > On Thu, 2020-11-12 at 12:22 +0100, Michal Hocko wrote: > > > [Cc Chris for i915 and Andray] > > > > > > On Thu 05-11-20 14:15:08, Rik van Riel wrote: > > > > Matthew Wilcox pointed out that the i915 driver > > > > opportunistically > > > > allocates tmpfs memory, but will happily reclaim some of its > > > > pool if no memory is available. > > > > > > It would be good to explicitly mention the requested gfp flags > > > for > > > those > > > allocations. i915 uses __GFP_NORETRY | __GFP_NOWARN, or > > > GFP_KERNEL. > > > Is > > > __shmem_rw really meant to not allocate from highmeme/movable > > > zones? > > > Can > > > it be ever backed by THPs? > > > > You are right, I need to copy the zone flags __GFP_DMA > > through > > __GFP_MOVABLE straight from the limiting gfp_mask > > into the gfp_mask used for THP allocations, and not use > > the default THP zone flags if the caller specifies something > > else. > > > > I'll send out a new version that fixes that. > > Can we make one step back here and actually check whether all this is > actually needed for those shmem users before adding more hacks here > and > there? It doesn't look like that is needed, after all. The i915 driver seems to support having its buffer in highmem, the shmem_pwrite and shmem_pread functions both do kmap/kunmap. -- All Rights Reversed.
Attachment:
signature.asc
Description: This is a digitally signed message part
