[Intel-gfx] [PATCH] memcg, shmem: fix shmem migration to use lrucare. (was: Re: memcontrol.c BUG)

2015-02-02 Thread Michal Hocko
On Thu 29-01-15 18:04:15, Hugh Dickins wrote: On Wed, 28 Jan 2015, Michal Hocko wrote: On Wed 28-01-15 08:48:52, Chris Wilson wrote: On Wed, Jan 28, 2015 at 08:13:06AM +1000, Dave Airlie wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1165369 ov 18 09:23:22 elissa.gathman.org

Re: [Intel-gfx] memcontrol.c BUG

2015-01-28 Thread Michal Hocko
above 4GiB. */ mask = ~__GFP_HIGHMEM; mask |= __GFP_DMA32; } -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] WARNING: CPU: 0 PID: 3634 at drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank

2015-07-08 Thread Michal Hocko
both runs attached. -- Michal Hocko SUSE Labs log.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] WARNING: CPU: 0 PID: 3634 at drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank

2015-07-08 Thread Michal Hocko
to understand a bit better what's going on there. And 0xf debug level seem to paper over the problem because I do not see the warning even with 4.1 where I am able to reproduce this reliably. This suggests this is a timing sensitive issue. -- Michal Hocko SUSE Labs

Re: [Intel-gfx] [PATCH v2 1/2] mm: Export nr_swap_pages

2015-12-08 Thread Michal Hocko
On Mon 07-12-15 11:48:31, Johannes Weiner wrote: > On Mon, Dec 07, 2015 at 02:48:12PM +0100, Michal Hocko wrote: > > On Fri 04-12-15 15:58:53, Chris Wilson wrote: > > > Some modules, like i915.ko, use swappable objects and may try to swap > > > them out under memory

Re: [Intel-gfx] [PATCH v2 1/2] mm: Export nr_swap_pages

2015-12-08 Thread Michal Hocko
> the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/2] mm: Export nr_swap_pages

2015-12-08 Thread Michal Hocko
aintenance burden in future. I think it is natural to export symbols which are consumed by modules and that will be get_nr_swap_pages(). I do not even understand the resistance against that. Anyway I am not going to argue about it more. I have raised my review comment and leave the d

Re: [Intel-gfx] [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags

2016-10-19 Thread Michal Hocko
would require FOLL_FORCE for access_remote_vm? I mean FOLL_FORCE is a really non-trivial thing. It doesn't obey vma permissions so we should really minimize its usage. Do all of those users really need FOLL_FORCE? Anyway I would rather see the flag explicit and use

Re: [Intel-gfx] [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

2016-10-19 Thread Michal Hocko
On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote: > On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote: > > I am wondering whether we can go further. E.g. it is not really clear to > > me whether we need an explicit FOLL_REMOTE when we can in fact check > > mm !=

Re: [Intel-gfx] [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags

2016-10-19 Thread Michal Hocko
On Wed 19-10-16 09:40:45, Lorenzo Stoakes wrote: > On Wed, Oct 19, 2016 at 10:13:52AM +0200, Michal Hocko wrote: > > On Wed 19-10-16 09:59:03, Jan Kara wrote: > > > On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote: > > > > This patch removes the write par

Re: [Intel-gfx] [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags

2016-10-19 Thread Michal Hocko
On Wed 19-10-16 10:06:46, Lorenzo Stoakes wrote: > On Wed, Oct 19, 2016 at 10:52:05AM +0200, Michal Hocko wrote: > > yes this is the desirable and expected behavior. > > > > > wonder if this is desirable behaviour or whether this ought to be limited > > > to >

Re: [Intel-gfx] [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

2016-10-18 Thread Michal Hocko
_FORCE users was always a nightmare and the flag behavior is really subtle so we should better be explicit about it. I haven't gone through each patch separately but rather applied the whole series and checked the resulting diff. This all seems OK to me and feel free to add Acked-by: Michal Hocko <mho

Re: [Intel-gfx] [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

2016-10-20 Thread Michal Hocko
On Wed 19-10-16 10:23:55, Dave Hansen wrote: > On 10/19/2016 10:01 AM, Michal Hocko wrote: > > The question I had earlier was whether this has to be an explicit FOLL > > flag used by g-u-p users or we can just use it internally when mm != > > current->mm > >

Re: [Intel-gfx] [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

2016-10-19 Thread Michal Hocko
On Wed 19-10-16 09:49:43, Dave Hansen wrote: > On 10/19/2016 02:07 AM, Michal Hocko wrote: > > On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote: > >> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote: > >>> I am wondering whether we can go further. E.g. it i

Re: [Intel-gfx] GPU hangs and X shot down with 4.11-rc6

2017-04-26 Thread Michal Hocko
On Tue 25-04-17 21:03:32, Chris Wilson wrote: > On Tue, Apr 25, 2017 at 06:41:20PM +0200, Michal Hocko wrote: > > Hi, > > I have just experienced X being shut down once with 4.11-rc2 and 2 times > > with 4.11-rc6 kernel. I do not remember seeing something like this >

[Intel-gfx] GPU hangs and X shot down with 4.11-rc6

2017-04-25 Thread Michal Hocko
oes this ring bells? The GPU crash dump is attached in case it is useful. Let me know if you need additional information. Thanks! -- Michal Hocko SUSE Labs gpu_dump.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.

Re: [Intel-gfx] i915 memory allocation failure..

2017-06-05 Thread Michal Hocko
s this week. It would help to send me a patch or two which would use the new flag in your code so that I can add it/thme to the series and add some other explamples for the justification? -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Remove __GFP_NORETRY from our buffer allocator

2017-06-08 Thread Michal Hocko
t; Fixes: 24f8e00a8a2e ("drm/i915: Prefer to report ENOMEM rather than incur the > oom for gfx allocations") > Testcase: igt/gem_tiled_swapping > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com

Re: [Intel-gfx] [PATCH v2] drm/i915: Remove __GFP_NORETRY from our buffer allocator

2017-06-06 Thread Michal Hocko
On Mon 05-06-17 13:49:38, Chris Wilson wrote: > Quoting Michal Hocko (2017-06-05 13:26:30) > > On Mon 05-06-17 11:35:12, Chris Wilson wrote: > > > I tried __GFP_NORETRY in the belief that __GFP_RECLAIM was effective. It > > > struggles with handling reclaim via kswapd (t

Re: [Intel-gfx] [PATCH v2] drm/i915: Remove __GFP_NORETRY from our buffer allocator

2017-06-06 Thread Michal Hocko
: igt/gem_tiled_swapping > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > Cc: Daniel Vetter <daniel.vet...@ffwll.ch> > Cc: Michal Hocko <mho...@suse.com> > --- > drivers/gpu/drm/i915/i915_gem.c |

Re: [Intel-gfx] [PATCH v2] drm/i915: Remove __GFP_NORETRY from our buffer allocator

2017-06-06 Thread Michal Hocko
On Mon 05-06-17 14:39:17, Chris Wilson wrote: > Quoting Michal Hocko (2017-06-05 14:08:10) > > On Mon 05-06-17 13:49:38, Chris Wilson wrote: > > > Quoting Michal Hocko (2017-06-05 13:26:30) > > > > On Mon 05-06-17 11:35:12, Chris Wilson wrote: > > >

Re: [Intel-gfx] [PATCH v2] drm/i915: Remove __GFP_NORETRY from our buffer allocator

2017-06-06 Thread Michal Hocko
On Mon 05-06-17 16:04:55, Chris Wilson wrote: > Quoting Michal Hocko (2017-06-05 14:08:10) > > On Mon 05-06-17 13:49:38, Chris Wilson wrote: > > > Quoting Michal Hocko (2017-06-05 13:26:30) > > > > On Mon 05-06-17 11:35:12, Chris Wilson wrote: > > >

Re: [Intel-gfx] i915 memory allocation failure..

2017-06-05 Thread Michal Hocko
ot;don't > try at all". In people trying to fight the "retry forever", we seem to > have gone too far in the "don't even bother, just return NULL" > direction. Yes, I am trying to convert GFP_REPEAT into something like that for quite some time. See http://lkml.ker

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: Remove __GFP_NORETRY from our buffer allocator

2017-06-09 Thread Michal Hocko
pping > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com> > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > Cc: Daniel Vetter <daniel.vet...@ffwll.ch> > Cc: Michal Hocko <mho...@suse.c

Re: [Intel-gfx] [PATCH v2 5/5] drm/i915: Start writeback from the shrinker

2017-06-09 Thread Michal Hocko
ahtinen <joonas.lahti...@linux.intel.com> > Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com> > Cc: Matthew Auld <matthew.a...@intel.com> > Cc: Daniel Vetter <daniel.vet...@ffwll.ch> > Cc: Michal Hocko <mho...@suse.com> > --- > drivers/gpu/drm

Re: [Intel-gfx] [PATCH v2 5/5] drm/i915: Start writeback from the shrinker

2017-06-09 Thread Michal Hocko
On Fri 09-06-17 12:51:57, Chris Wilson wrote: > Quoting Michal Hocko (2017-06-09 12:17:26) > > [Add Hugh] > > > > On Fri 09-06-17 12:03:50, Chris Wilson wrote: > > > When we are called to relieve mempressue via the shrinker, the only way > > > we can make pr

Re: [Intel-gfx] [RFC] drm/i915: Start writeback from the shrinker

2017-06-06 Thread Michal Hocko
sitive tasks (as we are just extending the > impact of swap thrashing to them). > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com> > Cc: Matthew Auld &

Re: [Intel-gfx] [RFC] mm, drm/i915: Mark pinned shmemfs pages as unevictable

2017-06-06 Thread Michal Hocko
;ch...@chris-wilson.co.uk> > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > Cc: Matthew Auld <matthew.a...@intel.com> > Cc: Dave Hansen <dave.han...@intel.com> > Cc: "Kirill A . Shutemov" <kirill.shute...@linux.intel.com> > Cc: Andrew M

Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.

2017-10-02 Thread Michal Hocko
is really nasty! And I would argue that this is an abuse of the oom notifier interface from the virtio code. OOM notifiers are an ugly hack on its own but all its users have to be really careful to not depend on any allocation request because that is a straight deadlock situation. I do not think

Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.

2017-10-02 Thread Michal Hocko
On Mon 02-10-17 17:11:55, Michael S. Tsirkin wrote: > On Mon, Oct 02, 2017 at 01:50:35PM +0200, Michal Hocko wrote: [...] > > and some > > other call path is allocating while holding the lock. But you seem to be > > right and > > leak_balloon > > tell_

Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.

2017-10-02 Thread Michal Hocko
On Mon 02-10-17 17:29:47, Michael S. Tsirkin wrote: > On Mon, Oct 02, 2017 at 04:19:00PM +0200, Michal Hocko wrote: > > On Mon 02-10-17 17:11:55, Michael S. Tsirkin wrote: > > > On Mon, Oct 02, 2017 at 01:50:35PM +0200, Michal Hocko wrote: > > [...] > > > &

Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.

2017-10-02 Thread Michal Hocko
On Mon 02-10-17 20:33:52, Tetsuo Handa wrote: > Michal Hocko wrote: > > [Hmm, I do not see the original patch which this has been a reply to] > > urbl.hostedemail.com and b.barracudacentral.org blocked my IP address, > and the rest are "Recipient address rejected: Greylist

Re: [Intel-gfx] [RFC] mm, drm/i915: Mark pinned shmemfs pages as unevictable

2017-08-21 Thread Michal Hocko
On Sat 19-08-17 14:15:35, Chris Wilson wrote: > Quoting Michal Hocko (2017-06-06 13:14:18) > > On Tue 06-06-17 13:04:36, Chris Wilson wrote: > > > Similar in principle to the treatment of get_user_pages, pages that > > > i915.ko acquires from shmemfs are not imm

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-02 Thread Michal Hocko
On Mon 02-07-18 11:14:58, Christian König wrote: > Am 27.06.2018 um 09:44 schrieb Michal Hocko: > > This is the v2 of RFC based on the feedback I've received so far. The > > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly > > because I have no i

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-02 Thread Michal Hocko
On Mon 02-07-18 14:24:29, Christian König wrote: > Am 02.07.2018 um 14:20 schrieb Michal Hocko: > > On Mon 02-07-18 14:13:42, Christian König wrote: > > > Am 02.07.2018 um 13:54 schrieb Michal Hocko: > > > > On Mon 02-07-18 11:14:58, Christian König wrote: > >

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-02 Thread Michal Hocko
On Mon 02-07-18 14:13:42, Christian König wrote: > Am 02.07.2018 um 13:54 schrieb Michal Hocko: > > On Mon 02-07-18 11:14:58, Christian König wrote: > > > Am 27.06.2018 um 09:44 schrieb Michal Hocko: > > > > This is the v2 of RFC based on the feedback I've received

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-02 Thread Michal Hocko
would simply back of without releasing any memory. The patch should help to reclaim some memory. > But do you know a way to let the OOM killer kill a specific process? Yes, you can set its oom_score_adj to 1000 which means always select that task. -- M

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-06-25 Thread Michal Hocko
On Mon 25-06-18 10:01:03, Michal Hocko wrote: > On Fri 22-06-18 16:09:06, Felix Kuehling wrote: > > On 2018-06-22 11:24 AM, Michal Hocko wrote: > > > On Fri 22-06-18 17:13:02, Christian König wrote: > > >> Hi Michal, > > >> > > >> [Adding F

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-06-25 Thread Michal Hocko
On Fri 22-06-18 16:09:06, Felix Kuehling wrote: > On 2018-06-22 11:24 AM, Michal Hocko wrote: > > On Fri 22-06-18 17:13:02, Christian König wrote: > >> Hi Michal, > >> > >> [Adding Felix as well] > >> > >> Well first of all you have a miscon

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-06-22 Thread Michal Hocko
[Resnding with the CC list fixed] On Fri 22-06-18 18:40:26, Michal Hocko wrote: > On Fri 22-06-18 12:18:46, Jerome Glisse wrote: > > On Fri, Jun 22, 2018 at 05:57:16PM +0200, Michal Hocko wrote: > > > On Fri 22-06-18 16:36:49, Chris Wilson wrote: > > > > Quoting Mic

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-06-22 Thread Michal Hocko
[Hmm, the cc list got mangled somehow - you have just made many people to work for suse ;) and to kvack.org in the preious one - fixed up hopefully] On Fri 22-06-18 17:07:21, Chris Wilson wrote: > Quoting Michal Hocko (2018-06-22 16:57:16) > > On Fri 22-06-18 16:36:49, Chris Wil

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-06-22 Thread Michal Hocko
On Fri 22-06-18 16:36:49, Chris Wilson wrote: > Quoting Michal Hocko (2018-06-22 16:02:42) > > Hi, > > this is an RFC and not tested at all. I am not very familiar with the > > mmu notifiers semantics very much so this is a crude attempt to achieve > > what I need basica

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-06-27 Thread Michal Hocko
2001 From: Michal Hocko Date: Wed, 20 Jun 2018 15:03:20 +0200 Subject: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit There are several blockable mmu notifiers which might sleep

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-08-24 Thread Michal Hocko
On Fri 24-08-18 15:28:33, Christian König wrote: > Am 24.08.2018 um 15:24 schrieb Michal Hocko: > > On Fri 24-08-18 15:10:08, Christian König wrote: > > > Am 24.08.2018 um 15:01 schrieb Michal Hocko: > > > > On Fri 24-08-18 14:52:26, Christian König wrote: > >

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-08-24 Thread Michal Hocko
On Fri 24-08-18 22:02:23, Tetsuo Handa wrote: > On 2018/08/24 20:36, Michal Hocko wrote: > >> That is, this API seems to be currently used by only out-of-tree users. > >> Since > >> we can't check that nobody has memory allocation dependency, I think that > >&

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-08-24 Thread Michal Hocko
On Fri 24-08-18 15:44:03, Christian König wrote: > Am 24.08.2018 um 15:40 schrieb Michal Hocko: > > On Fri 24-08-18 15:28:33, Christian König wrote: > > > Am 24.08.2018 um 15:24 schrieb Michal Hocko: > > > > On Fri 24-08-18 15:10:08, Christian König wrote: > >

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-08-24 Thread Michal Hocko
On Fri 24-08-18 14:52:26, Christian König wrote: > Am 24.08.2018 um 14:33 schrieb Michal Hocko: [...] > > Thiking about it some more, I can imagine that a notifier callback which > > performs an allocation might trigger a memory reclaim and that in turn > > might trigger a n

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-08-24 Thread Michal Hocko
On Fri 24-08-18 15:10:08, Christian König wrote: > Am 24.08.2018 um 15:01 schrieb Michal Hocko: > > On Fri 24-08-18 14:52:26, Christian König wrote: > > > Am 24.08.2018 um 14:33 schrieb Michal Hocko: > > [...] > > > > Thiking about it some more, I can im

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-08-24 Thread Michal Hocko
about? From f7ac75277d526dccd011f343818dc6af627af2af Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Fri, 24 Aug 2018 15:32:24 +0200 Subject: [PATCH] mm, mmu_notifier: be explicit about range invalition non-blocking mode If invalidate_range_start is called for !blocking mode then all callbacks have

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-08-24 Thread Michal Hocko
On Fri 24-08-18 23:52:25, Tetsuo Handa wrote: > On 2018/08/24 22:32, Michal Hocko wrote: > > On Fri 24-08-18 22:02:23, Tetsuo Handa wrote: > >> I worry that (currently > >> out-of-tree) users of this API are involving work / recursion. > > > > I do not giv

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-08-24 Thread Michal Hocko
On Fri 24-08-18 13:43:16, Christian König wrote: > Am 24.08.2018 um 13:32 schrieb Michal Hocko: > > On Fri 24-08-18 19:54:19, Tetsuo Handa wrote: > > > Two more worries for this patch. > > > > > > > > > > > > > --- a/drivers/gpu/drm

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-08-24 Thread Michal Hocko
On Fri 24-08-18 13:57:52, Christian König wrote: > Am 24.08.2018 um 13:52 schrieb Michal Hocko: > > On Fri 24-08-18 13:43:16, Christian König wrote: [...] > > > That won't work like this there might be multiple > > > invalidate_range_start()/invalidate_range_e

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-08-24 Thread Michal Hocko
On Fri 24-08-18 14:18:44, Christian König wrote: > Am 24.08.2018 um 14:03 schrieb Michal Hocko: > > On Fri 24-08-18 13:57:52, Christian König wrote: > > > Am 24.08.2018 um 13:52 schrieb Michal Hocko: > > > > On Fri 24-08-18 13:43:16, Christian König wrote: > >

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-08-24 Thread Michal Hocko
trylock(>lock)) { + if (!blockable) + return -EAGAIN; + down_read(amn->lock); + } return 0; } @@ -199,8 +196,7 @@ static int amdgpu_mn_read_lock(struct amdgpu_mn *amn, bool blockable) */ static void amdgpu_mn_read_unlock(struc

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-08-24 Thread Michal Hocko
> That is, this API seems to be currently used by only out-of-tree users. Since > we can't check that nobody has memory allocation dependency, I think that > hmm_invalidate_range_start() should return -EAGAIN if blockable == false for > now. The code expects that the i

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-17 Thread Michal Hocko
On Mon 16-07-18 16:12:49, Andrew Morton wrote: > On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote: > > > From: Michal Hocko > > > > There are several blockable mmu notifiers which might sleep in > > mmu_notifier_invalidate_range_start and that is a problem

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-23 Thread Michal Hocko
On Mon 23-07-18 09:11:54, Michal Hocko wrote: > On Mon 23-07-18 09:03:06, Michal Hocko wrote: > > On Fri 20-07-18 17:09:02, Andrew Morton wrote: > > [...] > > > Please take a look? > > > > Are you OK to have these in a separate patch? > > Btw. I will

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-23 Thread Michal Hocko
On Fri 20-07-18 17:09:02, Andrew Morton wrote: [...] > Please take a look? Are you OK to have these in a separate patch? -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mail

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-23 Thread Michal Hocko
On Mon 23-07-18 09:03:06, Michal Hocko wrote: > On Fri 20-07-18 17:09:02, Andrew Morton wrote: > [...] > > Please take a look? > > Are you OK to have these in a separate patch? Btw. I will rebase this patch once oom stuff in linux-next settles. At least oom_lock remov

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-23 Thread Michal Hocko
On Fri 20-07-18 16:01:25, Andrew Morton wrote: > On Tue, 17 Jul 2018 10:12:01 +0200 Michal Hocko wrote: > > > > Any suggestions regarding how the driver developers can test this code > > > path? I don't think we presently have a way to fake an oom-killing > > &

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-19 Thread Michal Hocko
Does anybody see any reasons why this should get into mmotm tree? I do not want to rush this in but if general feeling is to push it for the upcoming merge window then I will not object. -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx

[Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-16 Thread Michal Hocko
From: Michal Hocko There are several blockable mmu notifiers which might sleep in mmu_notifier_invalidate_range_start and that is a problem for the oom_reaper because it needs to guarantee a forward progress so it cannot depend on any sleepable locks. Currently we simply back off and mark

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-25 Thread Michal Hocko
oom_reaper: reaped process %d (%s), now anon-rss:%lukB, > file-rss:%lukB, shmem-rss:%lukB\n", > task_pid_nr(tsk), tsk->comm, -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-25 Thread Michal Hocko
bit to have unified function exit paths. Suggested-by: Andrew Morton Signed-off-by: Michal Hocko " -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-24 Thread Michal Hocko
EMPAGES))); +out_finish: + trace_finish_task_reaping(tsk->pid); +out_unlock: up_read(>mmap_sem); - trace_finish_task_reaping(tsk->pid); - return true; + return ret; } #define MAX_OOM_REAP_RETRIES 10 -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-10 Thread Michal Hocko
On Tue 10-07-18 16:40:40, Leon Romanovsky wrote: > On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wrote: > > On Wed 27-06-18 09:44:21, Michal Hocko wrote: > > > This is the v2 of RFC based on the feedback I've received so far. The > > > code even compiles as a

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-11 Thread Michal Hocko
On Tue 10-07-18 19:20:20, Leon Romanovsky wrote: > On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wrote: > > On Tue 10-07-18 16:40:40, Leon Romanovsky wrote: > > > On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wrote: > > > > On Wed 27-06-1

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-11 Thread Michal Hocko
On Wed 11-07-18 13:14:47, Leon Romanovsky wrote: > On Wed, Jul 11, 2018 at 11:03:53AM +0200, Michal Hocko wrote: > > On Tue 10-07-18 19:20:20, Leon Romanovsky wrote: > > > On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wrote: > > > > On Tue 10-07-18 1

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-07-09 Thread Michal Hocko
On Wed 27-06-18 09:44:21, Michal Hocko wrote: > This is the v2 of RFC based on the feedback I've received so far. The > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly > because I have no idea how. > > Any further feedback is highly appreciated of cou

[Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-06-22 Thread Michal Hocko
From: Michal Hocko There are several blockable mmu notifiers which might sleep in mmu_notifier_invalidate_range_start and that is a problem for the oom_reaper because it needs to guarantee a forward progress so it cannot depend on any sleepable locks. Currently we simply back off and mark an oom

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

2018-06-22 Thread Michal Hocko
; mmu_notifier *mn, > > /* notification is exclusive, but interval is inclusive */ > > end -= 1; > > - amdgpu_mn_read_lock(rmn); > > + if (amdgpu_mn_read_lock(rmn, blockable)) > > + return -EAGAIN; > > it = interval_tree_iter_first(>objects, start, end); > > while (it) { > > @@ -262,6 +277,8 @@ static void amdgpu_mn_invalidate_range_start_hsa(struct > > mmu_notifier *mn, > > amdgpu_amdkfd_evict_userptr(mem, mm); > > } > > } > > + > > + return 0; > > } > > /** -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Mark pinned shmemfs pages as unevictable

2018-10-16 Thread Michal Hocko
able zone. Does mapping_gfp_constraint contains __GFP_MOVABLE? If yes, we want to drop it as well. Other than that the patch makes sense with my very limited knowlege of the i915 code of course. -- Michal Hocko SUSE Labs ___ Intel-gfx mailing

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Mark pinned shmemfs pages as unevictable

2018-10-16 Thread Michal Hocko
On Tue 16-10-18 19:31:06, Chris Wilson wrote: > Quoting Michal Hocko (2018-10-16 19:21:55) > > On Wed 17-10-18 01:43:00, Kuo-Hsin Yang wrote: > > > The i915 driver use shmemfs to allocate backing storage for gem objects. > > > These shmemfs pages can be

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Mark pinned shmemfs pages as unevictable

2018-10-18 Thread Michal Hocko
nonymous LRU lists. You would have to generate a swapout workload to test this properly. On the other hand if mapping_set_unevictable has really a measurably bad performance impact then this is probably not worth much because most workloads are swap modest. -- Michal Hocko SUSE Labs ___

Re: [Intel-gfx] [PATCH v3] mm, drm/i915: mark pinned shmemfs pages as unevictable

2018-10-31 Thread Michal Hocko
ot reclaim anon LRUs at all. Maybe I have misunderstood the test though. I am also wondering whether unevictable pages culling can be really visible when we do the anon LRU reclaim because the swap path is quite expensinve on its own. -- Michal Hocko SUSE Labs __

Re: [Intel-gfx] [PATCH v3] mm, drm/i915: mark pinned shmemfs pages as unevictable

2018-10-31 Thread Michal Hocko
On Wed 31-10-18 07:40:14, Dave Hansen wrote: > On 10/31/18 7:24 AM, Michal Hocko wrote: > > I am also wondering whether unevictable pages culling can be > > really visible when we do the anon LRU reclaim because the swap path is > > quite expensinve on its own.

Re: [Intel-gfx] [PATCH v3] mm, drm/i915: mark pinned shmemfs pages as unevictable

2018-11-01 Thread Michal Hocko
On Thu 01-11-18 19:28:46, Vovo Yang wrote: > On Thu, Nov 1, 2018 at 12:42 AM Michal Hocko wrote: > > On Wed 31-10-18 07:40:14, Dave Hansen wrote: > > > Didn't we create the unevictable lists in the first place because > > > scanning alone was observed to be so

Re: [Intel-gfx] [PATCH v4] mm, drm/i915: mark pinned shmemfs pages as unevictable

2018-11-05 Thread Michal Hocko
l.org/patch/9768741/ I would recommend using msg-id based url. > Cc: Chris Wilson > Cc: Michal Hocko > Cc: Joonas Lahtinen > Cc: Peter Zijlstra > Cc: Andrew Morton > Cc: Dave Hansen > Signed-off-by: Kuo-Hsin Yang other than that Acked-by: Michal Hocko [...] &g

Re: [Intel-gfx] [PATCH v4] mm, drm/i915: mark pinned shmemfs pages as unevictable

2018-11-05 Thread Michal Hocko
On Mon 05-11-18 14:02:09, Michal Hocko wrote: > On Mon 05-11-18 19:13:48, Kuo-Hsin Yang wrote: > > The i915 driver uses shmemfs to allocate backing storage for gem > > objects. These shmemfs pages can be pinned (increased ref count) by > > shmem_read_mapping_page_gfp()

Re: [Intel-gfx] [PATCH v4] mm, drm/i915: mark pinned shmemfs pages as unevictable

2018-11-05 Thread Michal Hocko
On Mon 05-11-18 22:33:13, Kuo-Hsin Yang wrote: > On Mon, Nov 5, 2018 at 9:02 PM Michal Hocko wrote: > > > > On Mon 05-11-18 19:13:48, Kuo-Hsin Yang wrote: [...] > > > + * @pvec: pagevec with pages to check > > > * > > > - * Checks pages for evictabi

Re: [Intel-gfx] [PATCH v5] mm, drm/i915: mark pinned shmemfs pages as unevictable

2018-11-06 Thread Michal Hocko
> > Export pagevec API check_move_unevictable_pages(). > > This patch was inspired by Chris Wilson's change [1]. > > [1]: https://patchwork.kernel.org/patch/9768741/ > > Cc: Chris Wilson > Cc: Joonas Lahtinen > Cc: Peter Zijlstra > Cc: Andrew Morton > Cc: Dave Hans

Re: [Intel-gfx] [PATCH v6] mm, drm/i915: mark pinned shmemfs pages as unevictable

2018-11-06 Thread Michal Hocko
ree needs that. Up to Andrew but this doesn't seem to be conflicting with anything that is going on in MM. -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] mm, drm/i915: mark pinned shmemfs pages as unevictable

2018-11-02 Thread Michal Hocko
On Fri 02-11-18 20:35:11, Vovo Yang wrote: > On Thu, Nov 1, 2018 at 9:10 PM Michal Hocko wrote: > > OK, so that explain my question about the test case. Even though you > > generate a lot of page cache, the amount is still too small to trigger > > pagecache mostly

Re: [Intel-gfx] [PATCH 1/4] mm: Check if mmu notifier callbacks are allowed to fail

2018-12-10 Thread Michal Hocko
going to help with testing then I do not have any objections of course. > v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for > the problematic case (Michal Hocko). Thanks! > Cc: Andrew Morton > Cc: Michal Hocko > Cc: "Christian König" > Cc: David Rientjes

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

2018-12-10 Thread Michal Hocko
, and that really has a different semantic, I think this makes some sense. The cotext is preemptible but we do not want notifier to sleep on any locks, WQ etc. > Suggested by Michal Hocko. > > Cc: Andrew Morton > Cc: Michal Hocko > Cc: David Rientjes > Cc: "Christian König

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

2018-12-10 Thread Michal Hocko
On Mon 10-12-18 15:47:11, Peter Zijlstra wrote: > On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote: > > I do not see any scheduler guys Cced and it would be really great to get > > their opinion here. > > > > On Mon 10-12-18 11:36:39, Daniel Vetter wrote:

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

2018-12-10 Thread Michal Hocko
On Mon 10-12-18 16:22:53, Peter Zijlstra wrote: > On Mon, Dec 10, 2018 at 04:01:59PM +0100, Michal Hocko wrote: > > On Mon 10-12-18 15:47:11, Peter Zijlstra wrote: > > > On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote: > > > > I do not see any sc

Re: [Intel-gfx] [PATCH 2/3] mm, notifier: Catch sleeping/blocking for !blockable

2018-11-23 Thread Michal Hocko
On Fri 23-11-18 13:38:38, Daniel Vetter wrote: > On Fri, Nov 23, 2018 at 12:12:37PM +0100, Michal Hocko wrote: > > On Thu 22-11-18 17:51:05, Daniel Vetter wrote: > > > We need to make sure implementations don't cheat and don't have a > > > possible schedule/blocking

Re: [Intel-gfx] [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail

2018-11-23 Thread Michal Hocko
On Fri 23-11-18 14:15:11, Daniel Vetter wrote: > On Fri, Nov 23, 2018 at 1:43 PM Michal Hocko wrote: > > On Fri 23-11-18 13:30:57, Daniel Vetter wrote: > > > On Fri, Nov 23, 2018 at 12:15:57PM +0100, Michal Hocko wrote: > > > > On Thu 22-11-18 17:51:04, Daniel Vett

Re: [Intel-gfx] [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail

2018-11-23 Thread Michal Hocko
On Fri 23-11-18 13:30:57, Daniel Vetter wrote: > On Fri, Nov 23, 2018 at 12:15:57PM +0100, Michal Hocko wrote: > > On Thu 22-11-18 17:51:04, Daniel Vetter wrote: > > > Just a bit of paranoia, since if we start pushing this deep into > > > callchains it's hard to s

Re: [Intel-gfx] [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail

2018-11-23 Thread Michal Hocko
of memory. And where the process is > gone already, so semantics of what exactly happens don't matter that much > anymore. Yes this was indeed the case. There is still the exit path which would do the rest of the work so we are not leaving anything behind. -- Michal Hocko SUSE Labs __

Re: [Intel-gfx] [PATCH 2/3] mm, notifier: Catch sleeping/blocking for !blockable

2018-11-23 Thread Michal Hocko
callsites trigger, and it's a bit ugly in the code flow. > But it gets the job done. Yeah, it is quite ugly. Especially because it makes DEBUG config bahavior much different. So is this really worth it? Has this already discovered any existing bug? > Cc: Andrew Morton > Cc: Michal Hocko

Re: [Intel-gfx] [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail

2018-11-23 Thread Michal Hocko
Is really backtrace that interesting? > Cc: Andrew Morton > Cc: Michal Hocko > Cc: "Christian König" > Cc: David Rientjes > Cc: Daniel Vetter > Cc: "Jérôme Glisse" > Cc: linux...@kvack.org > Cc: Paolo Bonzini > Signed-off-by: Daniel Vetter

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

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 SUS

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

2019-05-21 Thread Michal Hocko
ocking API if this is a real problem. The above code just doesn't make any sense. We have a blocking API called and wrapped by non-blocking one. -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

2019-05-21 Thread Michal Hocko
s on top, but Michal > said those are less of a problem because spinlocks can't have an > indirect dependency upon the page allocator and hence close the loop > with the oom reaper. > > Suggested by Michal Hocko. > > v2: > - Improve commit message (Michal) > - Also check

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

2019-05-21 Thread Michal Hocko
leep() debug checks. Add a non_block_start/end() > > pair to annotate these. > > Just putting preempt on/off around these is not sufficient? It is not a critical section. It is a _debugging_ facility to help discover blocking contexts. -- Michal Hocko SUSE Labs __

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 > &g

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

2019-08-16 Thread Michal Hocko
On Fri 16-08-19 09:19:06, Jason Gunthorpe wrote: > On Fri, Aug 16, 2019 at 10:10:29AM +0200, Michal Hocko wrote: > > On Thu 15-08-19 17:13:23, Jason Gunthorpe wrote: > > > On Thu, Aug 15, 2019 at 09:35:26PM +0200, Michal Hocko wrote: > > > > > > > > The l

  1   2   >