[Intel-gfx] [PATCH 2/2] drm/i915: Make GPU pages movable

[Hugh Dickins]

On Tue, 22 Nov 2016, Matthew Auld wrote:
> On 9 November 2016 at 18:36, Hugh Dickins <hughd at google.com> wrote:
> > On Wed, 9 Nov 2016, Daniel Vetter wrote:
> >>
> >> Hi all -mm folks!
> >>
> >> Any feedback on these two? It's kinda an intermediate step towards a
> >> full-blown gemfs, and I think useful for that. Or do we need to go
> >> directly to our own backing storage thing? Aside from ack/nack from -mm I
> >> think this is ready for merging.
> >
> > I'm currently considering them at last: will report back later.
> >
> > Full-blown gemfs does not come in here, of course; but let me
> > fire a warning shot since you mention it: if it's going to use swap,
> > then we shall probably have to nak it in favour of continuing to use
> > infrastructure from mm/shmem.c.  I very much understand why you would
> > love to avoid that dependence, but I doubt it can be safely bypassed.
>
> Could you please elaborate on what specifically you don't like about
> gemfs implementing swap, just to make sure I'm following?

If we're talking about swap as implemented in mm/swapfile.c, and
managed for tmpfs mainly through shmem_getpage_gfp(): that's slippery
stuff, private to mm, and I would not want such trickiness duplicated
somewhere down in drivers/gpu/drm, where mm developers and drm developers
will keep on forgetting to keep it working correctly.

But you write of gemfs "implementing" swap (and I see Daniel wrote of
"our own backing storage"): perhaps you intend a disk or slow-mem file
of your own, dedicated to paging gemfs objects according to your own
rules, poked from memory reclaim via a shrinker.  I certainly don't
have the same quick objection to that: it may be a good way forward,
though I'm not at all sure (and would prefer a name distinct from
swap, so we wouldn't get confused - maybe gemswap).

Hugh