From: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
To: phasta@kernel.org, amd-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org
Cc: kernel-dev@igalia.com,
"Christian König" <christian.koenig@amd.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"Matthew Brost" <matthew.brost@intel.com>
Subject: Re: [RFC v4 12/16] drm/sched: Remove idle entity from tree
Date: Wed, 14 May 2025 10:22:00 +0100 [thread overview]
Message-ID: <bb12359a-a6d5-43fb-8a31-3aec1dcb7a52@igalia.com> (raw)
In-Reply-To: <0d94533502890e345a08fafc00919041c2f4b80d.camel@mailbox.org>
On 12/05/2025 14:03, Philipp Stanner wrote:
> On Fri, 2025-04-25 at 11:20 +0100, Tvrtko Ursulin wrote:
>> There is no need to keep entities with no jobs in the tree so lets
>> remove
>> it once the last job is consumed. This keeps the tree smaller which
>> is
>> nicer and more efficient as entities are removed and re-added on
>> every
>> popped job.
>
> That there is no need to do so doesn't imply that you can't keep them
> around. The commit message doesn't make the motivation clear
>
>>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
>> Cc: Christian König <christian.koenig@amd.com>
>> Cc: Danilo Krummrich <dakr@kernel.org>
>> Cc: Matthew Brost <matthew.brost@intel.com>
>> Cc: Philipp Stanner <phasta@kernel.org>
>> ---
>> drivers/gpu/drm/scheduler/sched_rq.c | 24 +++++++++++++-----------
>> 1 file changed, 13 insertions(+), 11 deletions(-)
>
> Since this doesn't simplify the code base, I think the only
> justification would be a somewhat decent performance gain. Does this
> patch result in that?
>
> Otherwise it's probably better to keep git-blame intact here.
I needed this for one of the earlier approaches and I *think* what
remains with the latest is just the fact it makes the run-queue contain
only runnable entities (which makes sense and is logical; run-queue <->
runnable). And that rb-tree re-balancing is cheaper with smaller trees
but in the grand scheme of things it is not something I even considered
attempting to measure.
I will re-consider the fate of this patch once more feedback on the
series as overall is received. Until then I don't think it makes sense
to churn it.
Btw another angle to this, which we touched upon with Christian before
is, if we end up not pruning the tree from unrunnable entities, then we
could drop the drm_sched_rq->entities list. Making a handful of caller
which walk it walk the tree instead.
Regards,
Tvrtko
>> diff --git a/drivers/gpu/drm/scheduler/sched_rq.c
>> b/drivers/gpu/drm/scheduler/sched_rq.c
>> index d477a027feb9..2cde89cf25fb 100644
>> --- a/drivers/gpu/drm/scheduler/sched_rq.c
>> +++ b/drivers/gpu/drm/scheduler/sched_rq.c
>> @@ -149,25 +149,27 @@ void drm_sched_rq_pop_entity(struct
>> drm_sched_entity *entity)
>> {
>> struct drm_sched_job *next_job;
>> struct drm_sched_rq *rq;
>> - ktime_t ts;
>>
>> /*
>> * Update the entity's location in the min heap according to
>> * the timestamp of the next job, if any.
>> */
>> + spin_lock(&entity->lock);
>> + rq = entity->rq;
>> + spin_lock(&rq->lock);
>> next_job = drm_sched_entity_queue_peek(entity);
>> - if (!next_job)
>> - return;
>> + if (next_job) {
>> + ktime_t ts;
>>
>> - if (drm_sched_policy == DRM_SCHED_POLICY_FIFO)
>> - ts = next_job->submit_ts;
>> - else
>> - ts = drm_sched_rq_get_rr_deadline(rq);
>> + if (drm_sched_policy == DRM_SCHED_POLICY_FIFO)
>> + ts = next_job->submit_ts;
>> + else
>> + ts = drm_sched_rq_get_rr_deadline(rq);
>>
>> - spin_lock(&entity->lock);
>> - rq = entity->rq;
>> - spin_lock(&rq->lock);
>> - drm_sched_rq_update_fifo_locked(entity, rq, ts);
>> + drm_sched_rq_update_fifo_locked(entity, rq, ts);
>> + } else {
>> + drm_sched_rq_remove_fifo_locked(entity, rq);
>> + }
>> spin_unlock(&rq->lock);
>> spin_unlock(&entity->lock);
>> }
>
next prev parent reply other threads:[~2025-05-14 9:22 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-25 10:20 [RFC v4 00/16] Fair DRM scheduler Tvrtko Ursulin
2025-04-25 10:20 ` [RFC v4 01/16] drm/sched: Add some scheduling quality unit tests Tvrtko Ursulin
2025-04-29 15:03 ` Christian König
2025-04-29 15:45 ` Michel Dänzer
2025-04-29 15:52 ` Christian König
2025-04-25 10:20 ` [RFC v4 02/16] drm/sched: Add some more " Tvrtko Ursulin
2025-04-29 15:07 ` Christian König
2025-04-25 10:20 ` [RFC v4 03/16] drm/sched: De-clutter drm_sched_init Tvrtko Ursulin
2025-04-29 15:16 ` Christian König
2025-04-25 10:20 ` [RFC v4 04/16] drm/sched: Avoid double re-lock on the job free path Tvrtko Ursulin
2025-05-12 12:49 ` Philipp Stanner
2025-05-12 12:57 ` Matthew Brost
2025-05-14 8:54 ` Tvrtko Ursulin
2025-05-14 8:46 ` Tvrtko Ursulin
2025-04-25 10:20 ` [RFC v4 05/16] drm/sched: Consolidate drm_sched_job_timedout Tvrtko Ursulin
2025-05-12 12:53 ` Philipp Stanner
2025-05-14 8:57 ` Tvrtko Ursulin
2025-04-25 10:20 ` [RFC v4 06/16] drm/sched: Consolidate drm_sched_rq_select_entity_rr Tvrtko Ursulin
2025-04-25 10:20 ` [RFC v4 07/16] drm/sched: Implement RR via FIFO Tvrtko Ursulin
2025-04-25 10:20 ` [RFC v4 08/16] drm/sched: Consolidate entity run queue management Tvrtko Ursulin
2025-04-25 10:20 ` [RFC v4 09/16] drm/sched: Move run queue related code into a separate file Tvrtko Ursulin
2025-04-25 10:20 ` [RFC v4 10/16] drm/sched: Free all finished jobs at once Tvrtko Ursulin
2025-05-12 12:56 ` Philipp Stanner
2025-05-14 9:00 ` Tvrtko Ursulin
2025-04-25 10:20 ` [RFC v4 11/16] drm/sched: Account entity GPU time Tvrtko Ursulin
2025-04-25 10:20 ` [RFC v4 12/16] drm/sched: Remove idle entity from tree Tvrtko Ursulin
2025-05-12 13:03 ` Philipp Stanner
2025-05-14 9:22 ` Tvrtko Ursulin [this message]
2025-04-25 10:20 ` [RFC v4 13/16] drm/sched: Add fair scheduling policy Tvrtko Ursulin
2025-04-25 10:20 ` [RFC v4 14/16] drm/sched: Remove FIFO and RR and simplify to a single run queue Tvrtko Ursulin
2025-04-26 12:20 ` kernel test robot
2025-04-25 10:20 ` [RFC v4 15/16] drm/sched: Queue all free credits in one worker invocation Tvrtko Ursulin
2025-04-25 10:20 ` [RFC v4 16/16] drm/sched: Embed run queue singleton into the scheduler Tvrtko Ursulin
2025-05-12 13:05 ` Philipp Stanner
2025-04-29 7:25 ` [RFC v4 00/16] Fair DRM scheduler Tvrtko Ursulin
2025-05-19 16:51 ` Pierre-Eric Pelloux-Prayer
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=bb12359a-a6d5-43fb-8a31-3aec1dcb7a52@igalia.com \
--to=tvrtko.ursulin@igalia.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kernel-dev@igalia.com \
--cc=matthew.brost@intel.com \
--cc=phasta@kernel.org \
/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.