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

[Greg KH]

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@xxxxxxx>
> > > > > > 
> > > > > > 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.

thanks,

greg k-h