[Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
Chris Wilson
chris at chris-wilson.co.uk
Thu Jul 1 13:19:21 CEST 2010
On Wed, 30 Jun 2010 18:24:04 -0700, Linus Torvalds <torvalds at linux-foundation.org> wrote:
> On Wed, Jun 30, 2010 at 4:07 PM, Linus Torvalds
> <torvalds at linux-foundation.org> wrote:
> >
> > That commit changes the page cache allocation to use
> >
> > + mapping_gfp_mask (mapping) |
> > + __GFP_COLD |
> > + gfpmask);
> >
> > if I read it right. And the default mapping_gfp_mask() is
> > GFP_HIGHUSER_MOVABLE, so I think you get all of
> > (__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL | __GFP_HIGHMEM)
> > set by default.
>
> .. and then I left out the one flag I _meant_ to have there, namely
> __GFP_MOVABLE.
>
> > The old code didn't just play games with ~__GFP_NORETRY and change
> > that at runtime (which was buggy - no locking, no protection, no
> > nothing), it also initialized the gfp mask. And that code also got
> > removed:
That code I added with the original shrinker patch, and the flags lifted
from the shmem defaults, tweaked to what seemed sane with the addition of
NORETRY and friends. I see that i915 is unique in using shmem as the page
allocator, which perhaps explains why this failure is not observed with
the ttm drivers. ttm uses two sets of gfp mask: HIGHUSER and USER | DMA32.
So replacing the mapping_gfp_mask() with HIGHUSER would seem appropriate.
And the interaction of MOVABLE could explain why hibernate broke with the
introduction of GEM.
* turns to his trusty copy of LDD to explain the various meanings of
gfp_t...
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list