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

2019-05-22 Thread Chris Wilson
Quoting Michal Hocko (2019-05-22 07:34:42) > On Wed 22-05-19 06:06:31, Tetsuo Handa wrote: > [...] > > Since OOM notifier will be called after shrinkers are attempted, > > can i915 move from OOM notifier to shrinker? > > That would be indeed preferable. OOM notifier is an API from hell. We were^W

Re: [PATCH] kernel.h: Add non_block_start/end()

2019-05-22 Thread Daniel Vetter
On Tue, May 21, 2019 at 11:06 PM Tetsuo Handa 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 bloc

Re: [PATCH] kernel.h: Add non_block_start/end()

2019-05-21 Thread Daniel Vetter
On Tue, May 21, 2019 at 12:46:38PM +0200, Michal Hocko wrote: > On Tue 21-05-19 12:06:11, Daniel Vetter wrote: > > In some special cases we must not block, but there's not a > > spinlock, preempt-off, irqs-off or similar critical section already > > that arms the might_sleep() debug checks. Add a n

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

2019-05-21 Thread Daniel Vetter
In some special cases we must not block, but there's not a spinlock, preempt-off, irqs-off or similar critical section already that arms the might_sleep() debug checks. Add a non_block_start/end() pair to annotate these. This will be used in the oom paths of mmu-notifiers, where blocking is not al

Re: [PATCH] kernel.h: Add non_block_start/end()

2019-05-21 Thread Michal Hocko
On Tue 21-05-19 14:43:38, Cristopher Lameter wrote: > On Tue, 21 May 2019, Daniel Vetter wrote: > > > In some special cases we must not block, but there's not a > > spinlock, preempt-off, irqs-off or similar critical section already > > that arms the might_sleep() debug checks. Add a non_block_sta

Re: [PATCH] kernel.h: Add non_block_start/end()

2019-05-21 Thread Christopher Lameter
On Tue, 21 May 2019, Daniel Vetter wrote: > In some special cases we must not block, but there's not a > spinlock, preempt-off, irqs-off or similar critical section already > that arms the might_sleep() debug checks. Add a non_block_start/end() > pair to annotate these. Just putting preempt on/of

Re: [PATCH] kernel.h: Add non_block_start/end()

2019-05-21 Thread Daniel Vetter
On Tue, May 21, 2019 at 08:24:53PM +0900, Tetsuo Handa wrote: > On 2019/05/21 20:11, Michal Hocko wrote: > > On Tue 21-05-19 20:04:34, Tetsuo Handa wrote: > >> On 2019/05/21 19:51, Michal Hocko wrote: > >>> On Tue 21-05-19 19:44:01, Tetsuo Handa wrote: > On 2019/05/21 19:06, Daniel Vetter wrot

Re: [PATCH] kernel.h: Add non_block_start/end()

2019-05-21 Thread Michal Hocko
On Tue 21-05-19 12:06:11, Daniel Vetter wrote: > In some special cases we must not block, but there's not a > spinlock, preempt-off, irqs-off or similar critical section already > that arms the might_sleep() debug checks. Add a non_block_start/end() > pair to annotate these. > > This will be used

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

2019-05-21 Thread Daniel Vetter
In some special cases we must not block, but there's not a spinlock, preempt-off, irqs-off or similar critical section already that arms the might_sleep() debug checks. Add a non_block_start/end() pair to annotate these. This will be used in the oom paths of mmu-notifiers, where blocking is not al