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
