[PATCH v5 3/7] drm/sched: Move schedule policy to scheduler

[Luben Tuikov]

On 2023-10-16 11:08, Matthew Brost wrote:
> On Fri, Oct 13, 2023 at 01:45:08PM -0400, Luben Tuikov wrote:
>> On 2023-10-11 19:58, Matthew Brost wrote:
>>> Rather than a global modparam for scheduling policy, move the scheduling
>>> policy to scheduler so user can control each scheduler policy.
>>>
>>> v2:
>>>   - s/DRM_SCHED_POLICY_MAX/DRM_SCHED_POLICY_COUNT (Luben)
>>>   - Only include policy in scheduler (Luben)
>>> v3:
>>>   - use a ternary operator as opposed to an if-control (Luben)
>>>   - s/DRM_SCHED_POLICY_DEFAULT/DRM_SCHED_POLICY_UNSET/ (Luben)
>>>   - s/default_drm_sched_policy/drm_sched_policy_default/ (Luben)
>>>   - Update commit message (Boris)
>>>   - Fix v3d build (CI)
>>>   - s/bad_policies/drm_sched_policy_mismatch/ (Luben)
>>>   - Don't update modparam doc (Luben)
>>> v4:
>>>   - Fix alignment in msm_ringbuffer_new (Luben / checkpatch)
>>>
>>> Reviewed-by: Luben Tuikov <luben.tuikov at amd.com>
>>> Signed-off-by: Matthew Brost <matthew.brost at intel.com>
>>
>> Hi,
>>
>> Forgot to mention this, but it is a very important process to note,
>> is that one should _never_ add someone else's R-V tag, _*UNLESS*_
>> a) there's an email from the person giving their review or ack, and
>> b) you're the one pushing the patch set into the tree.
>> If you're not the one pushing it into the tree, the maintainer will
>> add their R-V (after their reply-to follow-up email--see below),
>> including a Link: tag when they do "git am" after it's been all reviewed.
>>
>> And there's a reason for this.
>>
>> The reason is that when kernel maintainers (especially DRM via dim[1]) push
>> patches into the kernel, we want to add a Link: tag [2,3] pointing to
>> the thread where a) the patch was posted and b) where the reviewer gave
>> their Reviewed-by to the patch in a reply-all email, and at this moment
>> there is no such email for this patch.
>>
>> When a maintainer says "Do X, Y, Z, for an immediate R-V", this means
>> do those things, post it, and get a reply from the maintainer with an
>> R-V. This records how it happened and is very helpful when doing
>> data mining on how and why the code changed, via what patches, etc.
>>
>> I suspect there might be a v6, and we can do the R-V/Ack the right way
>> at that time. No big deal, but it's good to know in one place as it
>> is a bit scatter here and there in the kernel-doc.
>>
>> [1] https://gitlab.freedesktop.org/drm/maintainer-tools/
>> [2] git am --message-id
>> [3] https://docs.kernel.org/maintainer/
>> -- 
>> Regards,
>> Luben
>>
> 
> Again thanks for all the details of the development flow. Will read up
> on all of this.
> 
> Just to be to clear, when I post a rev6 I should not include a RB in the
> patches that recieved an RB in rev5 (or prior revs)? Rather a Cc would
> be better to alert the reviewer of another rev?

If you've received an R-B in an email and are subsequently reposting
the patch, append the R-B at the bottom of the tags, as a tool would do it.

As for Cc: tags, I never separate --to/--cc/Cc:. I just include everyone
in a Cc: tag, and my --to is just amdgfx or dri-dev. This way I don't need
to worry about cc-s and what not--it's all in the commit message. It makes
it easy for me, but you can do it whichever way is easier for you.

As to Cc field, if I want someone to see my email, I always Cc them, else the rules
put the email in some folder, where it may not be seen. But if their email
is in the Cc or To field, then I know they'll get it in their inbox.
-- 
Regards,
Luben