Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 30 Apr 2024 17:59:40 -0700 | From | Ricardo Neri <> | Subject | Re: [PATCH 2/4] thermal: intel: hfi: Tune the HFI thermal netlink event delay via debugfs |
| |
On Tue, Apr 30, 2024 at 04:52:52AM +0000, Zhang, Rui wrote: > On Mon, 2024-04-29 at 16:41 -0700, Ricardo Neri wrote: > > THe delay between an HFI interrupt and its corresponding thermal > > s/THe/The
Ah, I read the changelog 1000 times and still I misse this. Thanks!
> > > netlink > > event has so far been hard-coded to CONFIG_HZ jiffies. This may not > > suit > > the needs of all hardware configurations or listeners of events. > > > > If the update delay is too long, much of the information of > > consecutive > > hardware updates will be lost as the HFI delayed workqueue posts a > > new > > thermal netlink event only when there are no previous pending events. > > If > > the delay is too short, multiple, events may overwhelm listeners. > > > > Listeners are better placed to determine the delay of events. They > > know how > > quickly they can act on them effectively. They may also want to > > experiment > > with different values. > > > > Start a debugfs interface to tune the notification delay. > > Why this is implemented as debugfs rather than a module param?
Implementing as module param would require more work. In its current form, intel_hfi is not a module. Its entry points are device_initcall() (via therm_throt.c) and CPU hotplug.
I can look into implementing as a module param if folks think its a better solution.
| ![\](/images/icornerr.gif) |