All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jules Maselbas" <jmaselbas@zdiv.net>
To: "Christian König" <christian.koenig@amd.com>,
	"Philipp Stanner" <pstanner@redhat.com>,
	"Jules Maselbas" <jmaselbas@zdiv.net>,
	stable@vger.kernel.org
Cc: <gregkh@linuxfoundation.org>,
	"Tvrtko Ursulin" <tvrtko.ursulin@igalia.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Luben Tuikov" <ltuikov89@gmail.com>,
	"Matthew Brost" <matthew.brost@intel.com>
Subject: Re: [PATCH 6.12.y 1/3] drm/sched: Optimise drm_sched_entity_push_job
Date: Mon, 22 Sep 2025 22:50:50 +0200	[thread overview]
Message-ID: <DCZMJLU7W6M0.23UOORGDH2DIR@zdiv.net> (raw)
In-Reply-To: <57b2275c-d18a-418d-956f-2ed054ec555f@amd.com>

On Mon Sep 22, 2025 at 7:39 PM CEST, Christian König wrote:
> On 22.09.25 17:30, Philipp Stanner wrote:
>> On Mon, 2025-09-22 at 15:09 +0200, Jules Maselbas wrote:
>>> From: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
>>>
>>> commit d42a254633c773921884a19e8a1a0f53a31150c3 upstream.
>>>
>>> In FIFO mode (which is the default), both drm_sched_entity_push_job() and
>>> drm_sched_rq_update_fifo(), where the latter calls the former, are
>>> currently taking and releasing the same entity->rq_lock.
>>>
>>> We can avoid that design inelegance, and also have a miniscule
>>> efficiency improvement on the submit from idle path, by introducing a new
>>> drm_sched_rq_update_fifo_locked() helper and pulling up the lock taking to
>>> its callers.
>>>
>>> v2:
>>>  * Remove drm_sched_rq_update_fifo() altogether. (Christian)
>>>
>>> v3:
>>>  * Improved commit message. (Philipp)
>>>
>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
>>> Cc: Christian König <christian.koenig@amd.com>
>>> Cc: Alex Deucher <alexander.deucher@amd.com>
>>> Cc: Luben Tuikov <ltuikov89@gmail.com>
>>> Cc: Matthew Brost <matthew.brost@intel.com>
>>> Cc: Philipp Stanner <pstanner@redhat.com>
>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>> Signed-off-by: Philipp Stanner <pstanner@redhat.com>
>>> Link: https://patchwork.freedesktop.org/patch/msgid/20241016122013.7857-2-tursulin@igalia.com
>>> (cherry picked from commit d42a254633c773921884a19e8a1a0f53a31150c3)
>>> Signed-off-by: Jules Maselbas <jmaselbas@zdiv.net>
>> 
>> Am I interpreting this mail correctly: you want to get this patch into
>> stable?
>> 
>> Why? It doesn't fix a bug.
>
> Patch #3 in this series depends on the other two, but I agree that isn't a good idea.
Yes patch #3 fixes a freeze in amdgpu

> We should just adjust patch #3 to apply on the older kernel as well instead of backporting patches #1 and #2.
I initially modified patch #3 to use .rq_lock instead of .lock, but i didn't felt very confident with this modification.
Should i sent a new version with a modified patch #3 ?
If so, how the change should be reflected in the commit message ?
(I initially ask #kernelnewbies but ended pulling the two other patches)

Best,
Jules


  reply	other threads:[~2025-09-22 20:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-22 13:09 [PATCH 6.12.y 1/3] drm/sched: Optimise drm_sched_entity_push_job Jules Maselbas
2025-09-22 13:09 ` [PATCH 6.12.y 2/3] drm/sched: Re-group and rename the entity run-queue lock Jules Maselbas
2025-09-22 13:09 ` [PATCH 6.12.y 3/3] drm/amdgpu: fix task hang from failed job submission during process kill Jules Maselbas
2025-09-22 15:30 ` [PATCH 6.12.y 1/3] drm/sched: Optimise drm_sched_entity_push_job Philipp Stanner
2025-09-22 17:39   ` Christian König
2025-09-22 20:50     ` Jules Maselbas [this message]
2025-09-23 12:08       ` Philipp Stanner
2025-09-23 12:33         ` Christian König
2025-09-23 13:10           ` Philipp Stanner
2025-09-23 13:18             ` Christian König
2025-09-24 11:00           ` Danilo Krummrich
2025-09-24 12:22             ` Christian König
  -- strict thread matches above, loose matches on Subject: below --
2025-11-03  0:50 FAILED: patch "[PATCH] drm/sched: Fix race in drm_sched_entity_select_rq()" failed to apply to 6.12-stable tree gregkh
2025-11-03 12:44 ` [PATCH 6.12.y 1/3] drm/sched: Optimise drm_sched_entity_push_job Sasha Levin

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=DCZMJLU7W6M0.23UOORGDH2DIR@zdiv.net \
    --to=jmaselbas@zdiv.net \
    --cc=alexander.deucher@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=ltuikov89@gmail.com \
    --cc=matthew.brost@intel.com \
    --cc=pstanner@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=tvrtko.ursulin@igalia.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.