[Intel-gfx] [PATCH] Revert "drm/i915: Disallow pin ioctl completely for kms drivers"
Chris Wilson
chris at chris-wilson.co.uk
Tue Nov 25 21:47:10 CET 2014
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.
> 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.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list