[Intel-gfx] [PATCH] kernel.h: Add non_block_start/end()
Tetsuo Handa
penguin-kernel at i-love.sakura.ne.jp
Tue May 21 21:06:31 UTC 2019
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?
More information about the Intel-gfx
mailing list