[Intel-gfx] [PATCH] kernel.h: Add non_block_start/end()

[Daniel Vetter]

On Tue, May 21, 2019 at 11:06 PM Tetsuo Handa
<penguin-kernel at i-love.sakura.ne.jp> 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