On Tue, May 21, 2019 at 11:06 PM Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > > On 2019/05/21 23:44, Daniel Vetter wrote: > >>>> OOM notifiers should not depend on any locks or sleepable conditionals. > >>>> If some lock directly or indirectly depended on __GFP_DIRECT_RECLAIM, > >>>> it will deadlock. Thus, despite blocking API, this should effectively be > >>>> non-blocking. All OOM notifier users except i915 seems to be atomic, but > >>>> I can't evaluate i915 part... > >>> > >>> Read again what I've written, please > >>> > >> > >> Question to Daniel: Is i915's oom_notifier function atomic? > > > > It's supposed to not block too much at least, I don't think it's entirely > > atomic. Waking up the device (which we need to write some of the ptes) > > will take some time and I think acquires a few mutexes, but not 100% sure. > > > > If you want to see, send a patch to intel-gfx m-l and CI will pick it up > > and test with our farm of machines. > > As soon as a mutex is held, we can't expect it is atomic. We need to > manually inspect whether there is __GFP_DIRECT_RECLAIM dependency... > > Since OOM notifier will be called after shrinkers are attempted, > can i915 move from OOM notifier to shrinker? We also have a shrinker. The trouble is a bit that locking design in i915 is still not great (it's a lot better than it's bit), and iirc that's why we had the oom fallback. It unconditionally throws out a bunch of things we can do with less locking. Maybe we could stuff that into the shrinker now. Adding Chris. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
