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

2019-05-22 Thread Michal Hocko
On Wed 22-05-19 08:13:57, Chris Wilson wrote: > 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

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

Re: [Intel-gfx] [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

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

2019-05-22 Thread Michal Hocko
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. -- Michal Hocko SUSE Labs

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

2019-05-21 Thread Tetsuo Handa
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

Re: [Intel-gfx] [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

Re: [Intel-gfx] [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

Re: [Intel-gfx] [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

Re: [Intel-gfx] [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

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

2019-05-21 Thread Tetsuo Handa
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 wrote: > In some special cases we must not block, but there's not a

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

2019-05-21 Thread Michal Hocko
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 wrote: > >>> In some special cases we must not block, but there's not a > >>> spinlock, preempt-off, irqs-off or

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

2019-05-21 Thread Tetsuo Handa
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 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

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

2019-05-21 Thread Michal Hocko
On Tue 21-05-19 19:44:01, Tetsuo Handa wrote: > On 2019/05/21 19:06, 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()

Re: [Intel-gfx] [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

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

2019-05-21 Thread Tetsuo Handa
On 2019/05/21 19:06, 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 in