From: Chris Wilson <chris@chris-wilson.co.uk> To: intel-gfx@lists.freedesktop.org Cc: "Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>, dri-devel@lists.freedesktop.org Subject: [PATCH] drm/mm: Break long searches in fragmented address spaces Date: Fri, 7 Feb 2020 15:17:20 +0000 [thread overview] Message-ID: <20200207151720.2812125-1-chris@chris-wilson.co.uk> (raw) We try hard to select a suitable hole in the drm_mm first time. But if that is unsuccessful, we then have to look at neighbouring nodes, and this requires traversing the rbtree. Walking the rbtree can be slow (much slower than a linear list for deep trees), and if the drm_mm has been purposefully fragmented our search can be trapped for a long, long time. For non-preemptible kernels, we need to break up long CPU bound sections by manually checking for cond_resched(); similarly we should also bail out if we have been told to terminate. (In an ideal world, we would break for any signal, but we need to trade off having to perform the search again after ERESTARTSYS, which again may form a trap of making no forward progress.) Reported-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> --- drivers/gpu/drm/drm_mm.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c index 2a6e34663146..47d5de9ca0a8 100644 --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/drm/drm_mm.c @@ -45,6 +45,7 @@ #include <linux/export.h> #include <linux/interval_tree_generic.h> #include <linux/seq_file.h> +#include <linux/sched/signal.h> #include <linux/slab.h> #include <linux/stacktrace.h> @@ -366,6 +367,11 @@ next_hole(struct drm_mm *mm, struct drm_mm_node *node, enum drm_mm_insert_mode mode) { + /* Searching is slow; check if we ran out of time/patience */ + cond_resched(); + if (fatal_signal_pending(current)) + return NULL; + switch (mode) { default: case DRM_MM_INSERT_BEST: @@ -557,7 +563,7 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm, return 0; } - return -ENOSPC; + return signal_pending(current) ? -ERESTARTSYS : -ENOSPC; } EXPORT_SYMBOL(drm_mm_insert_node_in_range); -- 2.25.0 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Chris Wilson <chris@chris-wilson.co.uk> To: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Subject: [Intel-gfx] [PATCH] drm/mm: Break long searches in fragmented address spaces Date: Fri, 7 Feb 2020 15:17:20 +0000 [thread overview] Message-ID: <20200207151720.2812125-1-chris@chris-wilson.co.uk> (raw) We try hard to select a suitable hole in the drm_mm first time. But if that is unsuccessful, we then have to look at neighbouring nodes, and this requires traversing the rbtree. Walking the rbtree can be slow (much slower than a linear list for deep trees), and if the drm_mm has been purposefully fragmented our search can be trapped for a long, long time. For non-preemptible kernels, we need to break up long CPU bound sections by manually checking for cond_resched(); similarly we should also bail out if we have been told to terminate. (In an ideal world, we would break for any signal, but we need to trade off having to perform the search again after ERESTARTSYS, which again may form a trap of making no forward progress.) Reported-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> --- drivers/gpu/drm/drm_mm.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c index 2a6e34663146..47d5de9ca0a8 100644 --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/drm/drm_mm.c @@ -45,6 +45,7 @@ #include <linux/export.h> #include <linux/interval_tree_generic.h> #include <linux/seq_file.h> +#include <linux/sched/signal.h> #include <linux/slab.h> #include <linux/stacktrace.h> @@ -366,6 +367,11 @@ next_hole(struct drm_mm *mm, struct drm_mm_node *node, enum drm_mm_insert_mode mode) { + /* Searching is slow; check if we ran out of time/patience */ + cond_resched(); + if (fatal_signal_pending(current)) + return NULL; + switch (mode) { default: case DRM_MM_INSERT_BEST: @@ -557,7 +563,7 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm, return 0; } - return -ENOSPC; + return signal_pending(current) ? -ERESTARTSYS : -ENOSPC; } EXPORT_SYMBOL(drm_mm_insert_node_in_range); -- 2.25.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next reply other threads:[~2020-02-07 15:17 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-07 15:17 Chris Wilson [this message] 2020-02-07 15:17 ` [Intel-gfx] [PATCH] drm/mm: Break long searches in fragmented address spaces Chris Wilson 2020-02-07 19:04 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork 2020-02-11 8:54 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork 2020-02-11 22:56 ` [Intel-gfx] [PATCH] " Andi Shyti 2020-02-11 22:56 ` Andi Shyti 2020-02-14 0:34 ` Chris Wilson 2020-02-14 0:34 ` Chris Wilson 2020-03-31 13:27 Chris Wilson
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200207151720.2812125-1-chris@chris-wilson.co.uk \ --to=chris@chris-wilson.co.uk \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=zbigniew.kempczynski@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.