On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote: > > I still have my doubts about allowing fence waiting from within shrinkers. > > IMO ideally they should use a trywait approach, in order to allow memory > > allocation during command submission for drivers that > > publish fences before command submission. (Since early reservation object > > release requires that). > > Yeah it is a bit annoying, e.g. for drm/scheduler I think we'll end up > with a mempool to make sure it can handle it's allocations. > > > But since drivers are already waiting from within shrinkers and I take your > > word for HMM requiring this, > > Yeah the big trouble is HMM and mmu notifiers. That's the really awkward > one, the shrinker one is a lot less established. I really question if HW that needs something like DMA fence should even be using mmu notifiers - the best use is HW that can fence the DMA directly without having to get involved with some command stream processing. Or at the very least it should not be a generic DMA fence but a narrowed completion tied only into the same GPU driver's command completion processing which should be able to progress without blocking. The intent of notifiers was never to endlessly block while vast amounts of SW does work. Going around and switching everything in a GPU to GFP_ATOMIC seems like bad idea. > I've pinged a bunch of armsoc gpu driver people and ask them how much this > hurts, so that we have a clear answer. On x86 I don't think we have much > of a choice on this, with userptr in amd and i915 and hmm work in nouveau > (but nouveau I think doesn't use dma_fence in there). Right, nor will RDMA ODP. Jason
