From: Boris Brezillon <boris.brezillon@collabora.com>
To: Danilo Krummrich <dakr@redhat.com>
Cc: matthew.brost@intel.com, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, faith@gfxstrand.net,
luben.tuikov@amd.com, christian.koenig@amd.com
Subject: Re: [PATCH drm-misc-next v3] drm/sched: implement dynamic job-flow control
Date: Fri, 27 Oct 2023 10:25:16 +0200 [thread overview]
Message-ID: <20231027102516.0e4b00ef@collabora.com> (raw)
In-Reply-To: <20231026161431.5934-1-dakr@redhat.com>
Hi Danilo,
On Thu, 26 Oct 2023 18:13:00 +0200
Danilo Krummrich <dakr@redhat.com> wrote:
> Currently, job flow control is implemented simply by limiting the number
> of jobs in flight. Therefore, a scheduler is initialized with a credit
> limit that corresponds to the number of jobs which can be sent to the
> hardware.
>
> This implies that for each job, drivers need to account for the maximum
> job size possible in order to not overflow the ring buffer.
>
> However, there are drivers, such as Nouveau, where the job size has a
> rather large range. For such drivers it can easily happen that job
> submissions not even filling the ring by 1% can block subsequent
> submissions, which, in the worst case, can lead to the ring run dry.
>
> In order to overcome this issue, allow for tracking the actual job size
> instead of the number of jobs. Therefore, add a field to track a job's
> credit count, which represents the number of credits a job contributes
> to the scheduler's credit limit.
>
> Signed-off-by: Danilo Krummrich <dakr@redhat.com>
> ---
> Changes in V2:
> ==============
> - fixed up influence on scheduling fairness due to consideration of a job's
> size
> - If we reach a ready entity in drm_sched_select_entity() but can't actually
> queue a job from it due to size limitations, just give up and go to sleep
> until woken up due to a pending job finishing, rather than continue to try
> other entities.
> - added a callback to dynamically update a job's credits (Boris)
This callback seems controversial. I'd suggest dropping it, so the
patch can be merged.
Regards,
Boris
> - renamed 'units' to 'credits'
> - fixed commit message and comments as requested by Luben
>
> Changes in V3:
> ==============
> - rebased onto V7 of the "DRM scheduler changes for Xe" series by Matt
> - move up drm_sched_can_queue() instead of adding a forward declaration
> (Boris)
> - add a drm_sched_available_credits() helper (Boris)
> - adjust control flow in drm_sched_rq_select_entity_fifo() to Luben's proposal
> - re-phrase a few comments and fix a typo (Luben)
> - change naming of all structures credit fields and function parameters to the
> following scheme
> - drm_sched_job::credits
> - drm_gpu_scheduler::credit_limit
> - drm_gpu_scheduler::credit_count
> - drm_sched_init(..., u32 credit_limit, ...)
> - drm_sched_job_init(..., u32 credits, ...)
> - add proper documentation for the scheduler's job-flow control mechanism
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Danilo Krummrich <dakr@redhat.com>
Cc: airlied@gmail.com, daniel@ffwll.ch, matthew.brost@intel.com,
christian.koenig@amd.com, faith@gfxstrand.net,
luben.tuikov@amd.com, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH drm-misc-next v3] drm/sched: implement dynamic job-flow control
Date: Fri, 27 Oct 2023 10:25:16 +0200 [thread overview]
Message-ID: <20231027102516.0e4b00ef@collabora.com> (raw)
In-Reply-To: <20231026161431.5934-1-dakr@redhat.com>
Hi Danilo,
On Thu, 26 Oct 2023 18:13:00 +0200
Danilo Krummrich <dakr@redhat.com> wrote:
> Currently, job flow control is implemented simply by limiting the number
> of jobs in flight. Therefore, a scheduler is initialized with a credit
> limit that corresponds to the number of jobs which can be sent to the
> hardware.
>
> This implies that for each job, drivers need to account for the maximum
> job size possible in order to not overflow the ring buffer.
>
> However, there are drivers, such as Nouveau, where the job size has a
> rather large range. For such drivers it can easily happen that job
> submissions not even filling the ring by 1% can block subsequent
> submissions, which, in the worst case, can lead to the ring run dry.
>
> In order to overcome this issue, allow for tracking the actual job size
> instead of the number of jobs. Therefore, add a field to track a job's
> credit count, which represents the number of credits a job contributes
> to the scheduler's credit limit.
>
> Signed-off-by: Danilo Krummrich <dakr@redhat.com>
> ---
> Changes in V2:
> ==============
> - fixed up influence on scheduling fairness due to consideration of a job's
> size
> - If we reach a ready entity in drm_sched_select_entity() but can't actually
> queue a job from it due to size limitations, just give up and go to sleep
> until woken up due to a pending job finishing, rather than continue to try
> other entities.
> - added a callback to dynamically update a job's credits (Boris)
This callback seems controversial. I'd suggest dropping it, so the
patch can be merged.
Regards,
Boris
> - renamed 'units' to 'credits'
> - fixed commit message and comments as requested by Luben
>
> Changes in V3:
> ==============
> - rebased onto V7 of the "DRM scheduler changes for Xe" series by Matt
> - move up drm_sched_can_queue() instead of adding a forward declaration
> (Boris)
> - add a drm_sched_available_credits() helper (Boris)
> - adjust control flow in drm_sched_rq_select_entity_fifo() to Luben's proposal
> - re-phrase a few comments and fix a typo (Luben)
> - change naming of all structures credit fields and function parameters to the
> following scheme
> - drm_sched_job::credits
> - drm_gpu_scheduler::credit_limit
> - drm_gpu_scheduler::credit_count
> - drm_sched_init(..., u32 credit_limit, ...)
> - drm_sched_job_init(..., u32 credits, ...)
> - add proper documentation for the scheduler's job-flow control mechanism
next prev parent reply other threads:[~2023-10-27 8:25 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-26 16:13 [PATCH drm-misc-next v3] drm/sched: implement dynamic job-flow control Danilo Krummrich
2023-10-26 16:13 ` Danilo Krummrich
2023-10-26 21:13 ` Luben Tuikov
2023-10-27 1:03 ` Luben Tuikov
2023-10-27 7:17 ` Boris Brezillon
2023-10-27 7:17 ` Boris Brezillon
[not found] ` <794f9b45-db0d-4261-aefe-7da2ad0ed3b7@redhat.com>
2023-10-27 16:26 ` Boris Brezillon
2023-10-28 3:34 ` Luben Tuikov
2023-10-27 7:22 ` Christian König
2023-10-27 7:22 ` Christian König
2023-10-27 7:32 ` Boris Brezillon
2023-10-27 7:32 ` Boris Brezillon
2023-10-27 7:35 ` Christian König
2023-10-27 7:35 ` Christian König
2023-10-27 7:39 ` Boris Brezillon
2023-10-27 7:39 ` Boris Brezillon
2023-10-27 7:44 ` Christian König
2023-10-27 8:22 ` Boris Brezillon
2023-10-27 8:22 ` Boris Brezillon
2023-10-27 9:06 ` Christian König
2023-10-27 10:17 ` Boris Brezillon
2023-10-27 10:17 ` Boris Brezillon
2023-10-30 7:38 ` Christian König
2023-10-30 7:38 ` Christian König
2023-10-30 17:56 ` Danilo Krummrich
2023-10-30 17:56 ` Danilo Krummrich
2023-10-31 13:20 ` Christian König
2023-10-31 15:01 ` Danilo Krummrich
2023-10-31 15:01 ` Danilo Krummrich
[not found] ` <8d4a0870-f7d0-41ee-aa25-6488b6ea037a@amd.com>
[not found] ` <ZUPkfKzgKqhqQhMI@pollux>
[not found] ` <c91cf097-2ed3-4669-b9ae-b16b5f875b02@amd.com>
2023-11-06 16:46 ` Danilo Krummrich
2023-11-06 16:46 ` Danilo Krummrich
2023-11-07 9:13 ` Christian König
2023-11-07 9:13 ` Christian König
2023-11-07 13:03 ` Danilo Krummrich
2023-11-07 13:03 ` Danilo Krummrich
2023-10-27 8:25 ` Boris Brezillon [this message]
2023-10-27 8:25 ` Boris Brezillon
[not found] ` <8e117f9f-a01c-4242-8781-b2ed4969513b@redhat.com>
2023-10-27 16:31 ` Boris Brezillon
2023-10-28 3:37 ` Luben Tuikov
[not found] ` <a9215c37-61cd-4fbc-9f80-217daacd96bd@gmail.com>
[not found] ` <20231027184143.4427edb8@collabora.com>
2023-10-28 3:51 ` Luben Tuikov
2023-10-28 3:51 ` 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=20231027102516.0e4b00ef@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=christian.koenig@amd.com \
--cc=dakr@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=faith@gfxstrand.net \
--cc=linux-kernel@vger.kernel.org \
--cc=luben.tuikov@amd.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.