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