Re: [PATCH V1] accel/amdxdna: Add hardware scheduler time quantum support

[Mario Limonciello <mario.limonciello@amd.com>]

On 4/18/26 02:35, Greg KH wrote:
> On Tue, Apr 14, 2026 at 12:32:20PM -0500, Mario Limonciello wrote:
>>
>>
>> On 4/14/26 12:28, Lizhi Hou wrote:
>>>
>>> On 4/14/26 10:17, Mario Limonciello wrote:
>>>>
>>>>
>>>> On 4/14/26 12:16, Lizhi Hou wrote:
>>>>>
>>>>> On 4/14/26 09:58, Mario Limonciello wrote:
>>>>>>
>>>>>>
>>>>>> On 4/14/26 11:56, Lizhi Hou wrote:
>>>>>>> From: Max Zhen <max.zhen@amd.com>
>>>>>>>
>>>>>>> Add support for configuring the hardware scheduler time quantum to
>>>>>>> improve fairness across concurrent contexts.
>>>>>>>
>>>>>>> The scheduler enforces a fixed time slice per context, preventing
>>>>>>> long-running workloads from monopolizing the device and allowing
>>>>>>> other contexts to make forward progress.
>>>>>>>
>>>>>>> The default time quantum is 30ms and can be configured via the
>>>>>>> time_quantum_ms module parameter.
>>>>>>
>>>>>> Can you talk more about how you want to use it?  Adding new
>>>>>> module parameters is generally frowned upon in lieu of doing
>>>>>> something with debugfs at runtime.
>>>>>
>>>>> This is a static setting which is not supposed to change at
>>>>> runtime. So module parameter is used.
>>>>
>>>> But so what happens if user loads driver with default setting and
>>>> then unloads driver and loads with a different setting as module
>>>> option?
>>>>
>>>> Does this flow fall apart because the driver initially programmed 30ms?
>>>
>>> Reloading with new setting will overwrite the default setting. After the
>>> module is loaded, it is not supposed to change before unloading the
>>> module.
>>>
>>
>> + Greg
>>
>> Greg,
>>
>> How do you feel about a module parameter for this purpose?  Any other
>> suggestions if you don't like it?
> 
> module parameters should almost never never never be added to the
> kernel, ESPECIALLY if it is for a device-specific thing (like in a
> driver like this.)  Please don't do that.
> 
>> I was thinking a debugfs file still makes sense, but either the debugfs file
>> can do unbind/rebind internally or user using debugfs file can do the
>> unbind/bind sequence in sysfs after touching the debugfs file.
> 
> debugfs is for debugging, don't require it for functionality that a
> user/admin actually wants to do for a device as many distros and systems
> disable it entirely due to all of the security holes it exposes to
> admins.

It was for tuning purposes.  Max and team decided to make it a compile 
time macro.  Any tuning can be done by developers recompiling.