[RFC PATCH 2/4] drm/scheduler: implement a function to modify sched list

[Luben Tuikov]

On 2020-03-03 14:06, Christian König wrote:
> Am 02.03.20 um 21:47 schrieb Luben Tuikov:
>> On 2020-02-28 2:47 a.m., Christian König wrote:
>>> Am 28.02.20 um 06:08 schrieb Luben Tuikov:
>>>> On 2020-02-27 4:40 p.m., Nirmoy Das wrote:
>>>>> [SNIP]
>>>>> +	if (!(entity && sched_list && (num_sched_list == 0 || sched_list[0])))
>>>>> +		return -EINVAL;
>>>> This seems unmaintainable. I'd write it in its natural form:
>>> This is probably just copy & pasted from the init function and complete
>>> overkill here.
>> It should be an easy rejection then. Statements like this make
>> the code unmaintainable. Regardless of whether it was copy-and-pasted
>> I wanted to emphasize the lack of simplification of what
>> was being done.
> 
> The problem is even deeper. As you noticed as well this is checking for 
> in kernel coding error and not application errors.

We shouldn't check the in-kernel implementation itself. If the kernel
did this everywhere, it'd be twice the size. The kernel shouldn't be
second-guessing itself.

Another way to see this is to ask "what would the kernel do here
if XYZ was NULL", for instance?  For userspace, it's clear. For
the kernel, it shows inconsistent and incomplete implmentation--something
which should be fixed.

Another way of seeing this is, if you break out a function into separate
smaller functions, checking the input parameters in those leaf/helper
functions (code which had been part of the original big function), would
make the code larger and second-guessing itself.

That check shouldn't be there. The implementation should be consistent
and complete in order to show an elegant code.

> 
> That check shouldn't have been in the init function in the first place, 
> but nobody had time to look into that so far.
> 
>> We need to put intention and sense into what we're doing, scrutinizing
>> every line we put into a patch. This is why I suggested
>> the simplification here:
>>
>>>> int drm_sched_entity_modify_sched(struct drm_sched_entity *entity,
>>>> 				  struct drm_gpu_scheduler **sched_list,
>>>> 				  unsigned int num_sched_list)
>>>> {
>>>> 	if (entity && sched_list && (num_sched_list == 0 || sched_list[0] != NULL)) {
>>>> 		entity->sched_list = num_sched_list > 1 ? sched_list : NULL;
>>>> 		entity->num_sched_list = num_sched_list;
>>>> 		return 0;
>>>> 	} else {
>>>> 		return -EINVAL;
>>>> 	}
>>>> }
>>> Actually that's a rather bad idea. Error handling should always be in
>> I actually don't think that it is a "rather bad idea". At all.
>> I actually think that it makes this leaf function more clear to
>> understand as the conditional would read like a sentence in prose.
> 
> The condition is indeed easier to read, but for the sacrifice of earlier 
> return and keeping prerequisite checking out of the code.

You know the compiler can reorder such code and invert
this simple-for-the-compiler conditional. It is easier
for human readers who might need to maintain it.

For instance, when you asked "Do you guys remember why we
might not have a job here?" for amdgpu_ib_schedule()
in a recent email--if that code had been split into code for 
test purposes and real IB processing code, then that question
wouldn't even be on the table.

We need to achieve a balance of breaking out code and if-else
statements. At the moment the code show everything bunched
up into a single function and a ton of if-else statements,
with the pretense "to avoid duplication". Such duplication can be
avoided architecturally by redefining structures, what's in them,
and what arguments functions take.

> 
>> [SNIP]
>>> What we should do instead is just: WARN_ON(!num_sched_list || !sched_list);
>> Again, what does that *mean*? What does the check mean and what
>> does the num_sched_list == 0 or sched_list == NULL mean?
>> And how did we get into a situation like this where either or both
>> could be nil?
> 
> It's an in kernel coding error to do this. The caller should at least 
> always provide a list with some entries in it.
> 
> A WARN_ON() is appropriate since it helps to narrows down the incorrect 
> behavior following from that.
> 
>> Wouldn't it be better to simplify or re-architecture this (we only recently
>> decided to hide physical rings from user-space), so that the code
>> is elegant (meaning no if-else) yet flexible and straightforward?
> 
> That was not recently at all, hiding physical rings was done nearly 5 
> years ago shortly after the driver was initially released.
> 
>>>> Why not fix the architecture so that this is simply copied?
>>> We had that and moved away from it because the scheduler list is
>>> actually const and shouldn't be allocated with each entity (which we can
>>> easily have thousands of).
>> I think that peppering the code with if-else conditionals
>> everywhere as these patch-series into the DRM scheduler have been,
>> would make the code unmaintainable in the long run.
> 
> That's something I can agree on. Using a switch to map the priority to 
> the backend implementation seems like the best idea to me.

Do you mean you don't agree with anything I write? (If you have
to make a point of it here that *that* is something you can agree on?

I'd say, even a function is too heavy. A straightforward map should
be used, no function call, no switch (if-else in disguise), just
a map for instant lookup.

Regards,
Luben


> 
> E.g. function amdgpu_to_sched_priority() should not only map the IOCTL 
> values to the scheduler values, but also return the array which hw rings 
> to use.
> 
> Regards,
> Christian.
>