Quoting Matthew Auld (2020-11-05 16:02:38) > On Thu, 5 Nov 2020 at 15:45, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > > > Quoting Matthew Auld (2020-11-05 15:40:20) > > > On Thu, 5 Nov 2020 at 15:39, Matthew Auld > > > <matthew.william.auld@xxxxxxxxx> wrote: > > > > > > > > On Thu, 5 Nov 2020 at 10:11, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > > More the specialised interation with the physical GEM object from the > > > > > > > > Move interaction > > > > > > > > > pread/pwrite ioctl handler into the phys backend. > > > > > > > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > Reviewed-by: Matthew Auld <matthew.auld@xxxxxxxxx> > > > > > > Does this need Fixes btw? > > > > I was thinking so long as we land before dg1 it would be fine. If we did > > a fake lmem with no aperture, we would have problems already. But there's > > no user exposure, so no pressing need for cc:stable. > > I was thinking we could maybe be evil and achieve the same thing with > existing userspace, just requires the use of gtt_mmap to steal all of > the mappable aperture at the opportune time, such that > insert_mappable_node() still returns -ENOSPC? Or maybe I am > misunderstanding something. To steal all the aperture... Harder than you might think... Everything with full-ppgtt is pretty much impossible to arbitrarily pin the aperture. Many, many, many contexts would do. But we have to be sure not to leave any holes. The contexts can be anywhere, so we are looking at about 60k contexts before we start exhausting the GGTT, and there's no guarantee we didn't leave a hole large enough for the 4K GGTT slot. On global/aliasing, we can pin framebuffers into the aperture, but only two for each CRTC. Again, we have to leave no holes. That seems difficult with so few objects we can pin. The other angle is to try and prolong all the transient pins, but they are meant to be tiny ones... Wait. We can arbitrarily delay copy_from_user by using userfaultfd, so we would only need 64k threads or so to force ourselves into ENOSPC. That seems doable... -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
