[Intel-gfx] [PATCH] Revert "drm/i915: Disallow pin ioctl completely for kms drivers"

[Daniel Vetter]

On Tue, Nov 25, 2014 at 12:06:33PM +0000, Chris Wilson wrote:
> On Tue, Nov 25, 2014 at 01:01:39PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 25, 2014 at 11:42:56AM +0000, Chris Wilson wrote:
> > > This reverts commit c211a47c2c28562f8a3fff9e027be1a3ed9e154a.
> > > 
> > > This causes an unwarranteed API break for existing and active userspace.
> > > 
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > 
> > Hm, SNA still seems to be able to cope with this and I really don't see
> > the point of keeping this interface going and patching it up. With GEM the
> > kernel should be in control of shared resources, letting userspace in to
> > the game just leads to tears. And we have them now. Keeping pinning around
> > just because we've forgotten to properly disable it was ok with me, but
> > fixing it up when it starts to fall apart really isn't.
> 
> I strongly disagree. It is a powerful tool, equivalent to mlock(), and
> similar to mlock() has its uses.

There's multiple uses for mlock:
- One is preventing swapout for security reasons, and you can do that
  already (hackishly) with mlocking the cpu mmap.
- Another is preventing unbinding from address spaces/movement across numa
  domains, to avoid minor faults overheads. Softpin to avoid relocs sounds
  like the equivalant.

But none of the mlocks allow userspace to fix stuff into a limited shared
global resource like mappable ggtt for i915. A resource which is fully
managed by the kernel (except for pinning) and which can fragment badly.
mlock memory just brings oom a bit nearer (which can be handled with
cgroups and all that), but it doesn't hit fragmentation fun of a global
resource nearby. That is the part of pin I really don't like.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch