Quoting Joonas Lahtinen (2022-08-26 09:23:08) > Quoting John Harrison (2022-08-25 19:31:39) > > On 8/25/2022 00:15, Joonas Lahtinen wrote: > > > Quoting John Harrison (2022-08-24 21:45:09) > > >> We also don't want to tie the GuC logging buffer size to the DRM > > >> debugging output. Enabling kernel debug output can change timings and > > >> prevent the issue that one is trying to capture in the GuC log. And it > > >> seems unlikely we could add an entire new top level DRM debug flag just > > >> for an internal i915 only log buffer size. Plus drm.debug is explicitly > > >> stated as being dynamically changeable via sysfs at any time. The GuC > > >> log buffer size cannot be changed without reloading the i915 driver. Or > > >> at least, not without reloading the GuC, but we definitely don't want to > > >> create a UAPI for arbitrarily reloading the GuC. > > >> > > >> We can make these parameters 'unsafe' so that they taint the kernel if > > >> used. But this is exactly what module parameters are for - configuration > > >> that we don't want to hardcode as CONFIG options but which must be set > > >> at module load time. > > > It's better to have sane defaults. And if somebody wants something > > > strange, they can have a Kconfig behind EXPERT option. But even then > > > there should really be need for it. > > Define sane. > > I was hoping you would be the expert on that as you've suggested the > patch to begin with. > > Try to aim to cover >90% of the debug scenarios (that are only 0.001%) and > we're already only needing to recompile kernel in 1 per million cases. > > We can live with that. > > I will push a fixup to remove the module parameters, please figure the > rest out in a timely manner. John, what is the status of the followup patch here to configure those reasonable defaults? We shouldn't be ignoring this and proceed to pile other GuC patches on top. Regards, Joonas
