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

[Daniel Vetter]

On Tue, Nov 25, 2014 at 08:47:10PM +0000, Chris Wilson wrote:
> On Tue, Nov 25, 2014 at 02:34:02PM +0100, Daniel Vetter wrote:
> > 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. 
> 
> Pardon? What exactly about physical memory isn't a limited shared global
> resource? That's exactly why mlock() is privileged.

It doesn't fragment so badly. And we have cgroups to keep stuff in checks.

> > 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.
> 
> Indeed, that's exactly what I like about it. Locked memory that can't be
> lost due to insane fragmentation.

Well SNA isn't the only thing in town, which is why the kernel should manage
this. Otherwise we could just do userspace managed memory without
eviction for everyone, that way you're guaranteed to never attempt
anything which could fail.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch