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

[Mario Limonciello]

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

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