From: Philipp Stanner <pstanner@redhat.com>
To: Matthew Brost <matthew.brost@intel.com>
Cc: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
dakr@kernel.org, Luben Tuikov <ltuikov89@gmail.com>
Subject: Re: [PATCH 1/4] drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM
Date: Wed, 23 Oct 2024 09:56:42 +0200 [thread overview]
Message-ID: <07fd3c93da2bbb3c67a78e93ccd1c73705953b22.camel@redhat.com> (raw)
In-Reply-To: <Zxfq50e+uXfcsark@DUT025-TGLU.fm.intel.com>
On Tue, 2024-10-22 at 18:11 +0000, Matthew Brost wrote:
> On Tue, Oct 22, 2024 at 04:19:18PM +0200, Philipp Stanner wrote:
> > 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, [...]"
> >
>
> Sure.
>
> > > or dma-fences, and dma-fences are in the path of reclaim. Mark
> >
> > s/or/of
> >
>
> Yep.
>
> > > 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?
> >
>
> Yes.
>
> > If the change above is applied, could just say: "Create the work
> > queue
> > with WQ_MEM_RECLAIM so it can continue [...]"
> >
>
> Now you are confusing me.
I just was hinting at using singular instead of plural.
So
s/work queues/work queue
But that's just a nit
>
> > 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.
> >
>
> I can make that a bit more clear.
>
> > 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?
> >
>
> Bug - yea probably a fix tag then for backporting. Will add in next
> rev.
Cool, thx for clarifying!
P.
>
> >
> > >
> > > Cc: Luben Tuikov <ltuikov89@gmail.com>
> >
> > btw., how did you send this email? I couldn't find Luben on CC.
> > Added
> > him.
>
> git send-email...
>
> I may have forgot to include him on the Cc list.
>
> Matt
>
> >
> > 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;
> >
>
next prev parent reply other threads:[~2024-10-23 7:56 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
2024-10-22 18:11 ` Matthew Brost
2024-10-23 7:56 ` Philipp Stanner [this message]
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=07fd3c93da2bbb3c67a78e93ccd1c73705953b22.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.