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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxx>
> > > 
> > > 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux