All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Luben Tuikov <luben.tuikov@amd.com>, brolerliew <brolerliew@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/scheduler: set current_entity to next when remove from rq
Date: Thu, 27 Oct 2022 10:19:19 +0200	[thread overview]
Message-ID: <ac73b553-9173-4ac5-ef16-a95b8a8cd4f9@amd.com> (raw)
In-Reply-To: <9774ddd6-60d9-245c-77ac-59951c13b263@amd.com>

Am 27.10.22 um 10:07 schrieb Luben Tuikov:
> On 2022-10-27 03:01, Luben Tuikov wrote:
>> On 2022-10-25 13:50, Luben Tuikov wrote:
>>> Looking...
>>>
>>> Regards,
>>> Luben
>>>
>>> On 2022-10-25 09:35, Alex Deucher wrote:
>>>> + Luben
>>>>
>>>> On Tue, Oct 25, 2022 at 2:55 AM brolerliew <brolerliew@gmail.com> wrote:
>>>>> When entity move from one rq to another, current_entity will be set to NULL
>>>>> if it is the moving entity. This make entities close to rq head got
>>>>> selected more frequently, especially when doing load balance between
>>>>> multiple drm_gpu_scheduler.
>>>>>
>>>>> Make current_entity to next when removing from rq.
>>>>>
>>>>> Signed-off-by: brolerliew <brolerliew@gmail.com>
>>>>> ---
>>>>>   drivers/gpu/drm/scheduler/sched_main.c | 5 +++--
>>>>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
>>>>> index 2fab218d7082..00b22cc50f08 100644
>>>>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>>>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>>>>> @@ -168,10 +168,11 @@ void drm_sched_rq_remove_entity(struct drm_sched_rq *rq,
>>>>>          spin_lock(&rq->lock);
>>>>>
>>>>>          atomic_dec(rq->sched->score);
>>>>> -       list_del_init(&entity->list);
>>>>>
>>>>>          if (rq->current_entity == entity)
>>>>> -               rq->current_entity = NULL;
>>>>> +               rq->current_entity = list_next_entry(entity, list);
>>>>> +
>>>>> +       list_del_init(&entity->list);
>>>>>
>>>>>          if (drm_sched_policy == DRM_SCHED_POLICY_FIFO)
>>>>>                  drm_sched_rq_remove_fifo_locked(entity);
>>>>> --
>>>>> 2.34.1
>>>>>
>> Looks good. I'll pick it up into some other changes I've in tow, and repost
>> along with my changes, as they're somewhat related.
> Actually, the more I look at it, the more I think that we do want to set
> rq->current_entity to NULL in that function, in order to pick the next best entity
> (or scheduler for that matter), the next time around. See sched_entity.c,
> and drm_sched_rq_select_entity() where we start evaluating from the _next_
> entity.
>
> So, it is best to leave it to set it to NULL, for now.

Apart from that this patch here could cause a crash when the entity is 
the last one in the list.

In this case current current_entity would be set to an incorrect upcast 
of the head of the list.

Regards,
Christian.

>
> Regards,
> Luben
>


WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: Luben Tuikov <luben.tuikov@amd.com>, brolerliew <brolerliew@gmail.com>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/scheduler: set current_entity to next when remove from rq
Date: Thu, 27 Oct 2022 10:19:19 +0200	[thread overview]
Message-ID: <ac73b553-9173-4ac5-ef16-a95b8a8cd4f9@amd.com> (raw)
In-Reply-To: <9774ddd6-60d9-245c-77ac-59951c13b263@amd.com>

Am 27.10.22 um 10:07 schrieb Luben Tuikov:
> On 2022-10-27 03:01, Luben Tuikov wrote:
>> On 2022-10-25 13:50, Luben Tuikov wrote:
>>> Looking...
>>>
>>> Regards,
>>> Luben
>>>
>>> On 2022-10-25 09:35, Alex Deucher wrote:
>>>> + Luben
>>>>
>>>> On Tue, Oct 25, 2022 at 2:55 AM brolerliew <brolerliew@gmail.com> wrote:
>>>>> When entity move from one rq to another, current_entity will be set to NULL
>>>>> if it is the moving entity. This make entities close to rq head got
>>>>> selected more frequently, especially when doing load balance between
>>>>> multiple drm_gpu_scheduler.
>>>>>
>>>>> Make current_entity to next when removing from rq.
>>>>>
>>>>> Signed-off-by: brolerliew <brolerliew@gmail.com>
>>>>> ---
>>>>>   drivers/gpu/drm/scheduler/sched_main.c | 5 +++--
>>>>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
>>>>> index 2fab218d7082..00b22cc50f08 100644
>>>>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>>>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>>>>> @@ -168,10 +168,11 @@ void drm_sched_rq_remove_entity(struct drm_sched_rq *rq,
>>>>>          spin_lock(&rq->lock);
>>>>>
>>>>>          atomic_dec(rq->sched->score);
>>>>> -       list_del_init(&entity->list);
>>>>>
>>>>>          if (rq->current_entity == entity)
>>>>> -               rq->current_entity = NULL;
>>>>> +               rq->current_entity = list_next_entry(entity, list);
>>>>> +
>>>>> +       list_del_init(&entity->list);
>>>>>
>>>>>          if (drm_sched_policy == DRM_SCHED_POLICY_FIFO)
>>>>>                  drm_sched_rq_remove_fifo_locked(entity);
>>>>> --
>>>>> 2.34.1
>>>>>
>> Looks good. I'll pick it up into some other changes I've in tow, and repost
>> along with my changes, as they're somewhat related.
> Actually, the more I look at it, the more I think that we do want to set
> rq->current_entity to NULL in that function, in order to pick the next best entity
> (or scheduler for that matter), the next time around. See sched_entity.c,
> and drm_sched_rq_select_entity() where we start evaluating from the _next_
> entity.
>
> So, it is best to leave it to set it to NULL, for now.

Apart from that this patch here could cause a crash when the entity is 
the last one in the list.

In this case current current_entity would be set to an incorrect upcast 
of the head of the list.

Regards,
Christian.

>
> Regards,
> Luben
>


  reply	other threads:[~2022-10-27  8:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-25  6:18 [PATCH] drm/scheduler: set current_entity to next when remove from rq brolerliew
2022-10-25  6:18 ` brolerliew
2022-10-25 13:35 ` Alex Deucher
2022-10-25 17:50   ` Luben Tuikov
2022-10-27  7:01     ` Luben Tuikov
2022-10-27  8:07       ` Luben Tuikov
2022-10-27  8:07         ` Luben Tuikov
2022-10-27  8:19         ` Christian König [this message]
2022-10-27  8:19           ` Christian König
2022-10-27  8:24           ` Luben Tuikov
2022-10-27  8:24             ` Luben Tuikov
2022-10-27  9:00             ` broler Liew
2022-10-27  9:08               ` Christian König
2022-10-27 15:46                 ` Luben Tuikov
2022-10-27 15:46                   ` Luben Tuikov

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=ac73b553-9173-4ac5-ef16-a95b8a8cd4f9@amd.com \
    --to=christian.koenig@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=brolerliew@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luben.tuikov@amd.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.