All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philipp Stanner <pstanner@redhat.com>
To: Matthew Brost <matthew.brost@intel.com>,
	intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: dakr@kernel.org, Luben Tuikov <ltuikov89@gmail.com>
Subject: Re: [PATCH 1/4] drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM
Date: Tue, 22 Oct 2024 16:19:18 +0200	[thread overview]
Message-ID: <a5dd3b1d6b8da184ed16f5653faca95163b79340.camel@redhat.com> (raw)
In-Reply-To: <20241021175705.1584521-2-matthew.brost@intel.com>

On Mon, 2024-10-21 at 10:57 -0700, Matthew Brost wrote:
> DRM scheduler work queues are used to submit jobs, jobs are in the
> path

"scheduler work queues" is very generic, how about
"drm_gpu_scheduler.submit_wq is used to submit jobs, [...]"

> or dma-fences, and dma-fences are in the path of reclaim. Mark

s/or/of

> scheduler
> work queues with WQ_MEM_RECLAIM so these work queues can continue to
> make forward progress during reclaim.

It is just *one* queue (per scheduler) really, isn't it?

If the change above is applied, could just say: "Create the work queue
with WQ_MEM_RECLAIM so it can continue [...]"

So for my understanding: is this a performance optimization or is it a
bug? IOW, would forward progress just be delayed or entirely prevented?
Would be cool to state that a bit more clearly in the commit message.

Work-queue docu says "MUST":

``WQ_MEM_RECLAIM`` All wq which might be used in the memory reclaim
paths **MUST** have this flag set. The wq is guaranteed to have at
least one execution context regardless of memory pressure.

So it seems to me that this fixes a bug? Should it be backported in
your opinion?


> 
> Cc: Luben Tuikov <ltuikov89@gmail.com>

btw., how did you send this email? I couldn't find Luben on CC. Added
him.

Thx,
P.

> Cc: Danilo Krummrich <dakr@kernel.org>
> Cc: Philipp Stanner <pstanner@redhat.com>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> ---
>  drivers/gpu/drm/scheduler/sched_main.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 6e4d004d09ce..567811957c0f 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -1275,10 +1275,10 @@ int drm_sched_init(struct drm_gpu_scheduler
> *sched,
>   sched->own_submit_wq = false;
>   } else {
>  #ifdef CONFIG_LOCKDEP
> - sched->submit_wq = alloc_ordered_workqueue_lockdep_map(name, 0,
> + sched->submit_wq = alloc_ordered_workqueue_lockdep_map(name,
> WQ_MEM_RECLAIM,
>          &drm_sched_lockdep_map);
>  #else
> - sched->submit_wq = alloc_ordered_workqueue(name, 0);
> + sched->submit_wq = alloc_ordered_workqueue(name, WQ_MEM_RECLAIM);
>  #endif
>   if (!sched->submit_wq)
>   return -ENOMEM;


  reply	other threads:[~2024-10-22 14:19 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-21 17:57 [PATCH 0/4] Mark work queues with WQ_MEM_RECLAIM Matthew Brost
2024-10-21 17:57 ` [PATCH 1/4] drm/sched: Mark scheduler " Matthew Brost
2024-10-22 14:19   ` Philipp Stanner [this message]
2024-10-22 18:11     ` Matthew Brost
2024-10-23  7:56       ` Philipp Stanner
2024-10-21 17:57 ` [PATCH 2/4] drm/xe: Mark GGTT work queue " Matthew Brost
2024-10-22  5:06   ` Ghimiray, Himal Prasad
2024-10-22  5:34   ` Nilawar, Badal
2024-10-21 17:57 ` [PATCH 3/4] drm/xe: Mark G2H " Matthew Brost
2024-10-22  5:06   ` Ghimiray, Himal Prasad
2024-10-22  5:32     ` Nilawar, Badal
2024-10-21 17:57 ` [PATCH 4/4] drm/xe: Mark GT " Matthew Brost
2024-10-22  5:06   ` Ghimiray, Himal Prasad
2024-10-22  5:25   ` Nilawar, Badal
2024-10-21 18:21 ` ✓ CI.Patch_applied: success for Mark work queues " Patchwork
2024-10-21 18:21 ` ✓ CI.checkpatch: " Patchwork
2024-10-21 18:23 ` ✓ CI.KUnit: " Patchwork
2024-10-21 18:42 ` ✓ CI.Build: " Patchwork
2024-10-21 18:45 ` ✓ CI.Hooks: " Patchwork
2024-10-21 18:46 ` ✓ CI.checksparse: " Patchwork
2024-10-21 19:29 ` ✓ CI.BAT: " Patchwork
2024-10-22  0:34 ` ✗ CI.FULL: failure " Patchwork

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=a5dd3b1d6b8da184ed16f5653faca95163b79340.camel@redhat.com \
    --to=pstanner@redhat.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=ltuikov89@gmail.com \
    --cc=matthew.brost@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: link
Be 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.