On Tue, Oct 01, 2019 at 07:46:03PM +0200, Hans de Goede wrote: > Hi, > > On 01-10-2019 18:04, Stephen Gallagher wrote: > >On Mon, Sep 23, 2019 at 10:21 AM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > >> > >>https://fedoraproject.org/wiki/Changes/ThermalManagementWS > >> > >>== Summary == > >>Better thermal management and peak performance on Intel CPUs by > >>including thermald in the default install. > > > >>Install the packages and use e.g. turbostat to monitor the > >>performance. Improvements may only be visible if the non-free > >>dptfxtract package is also installed. > >> > > > >So, looking at the license of that tool, it seems to be fine to > >redistribute it unmodified... so what if we wrote a tool that would > >run the `acpidump` and `acpixtract` locally, submit it to a very > >simple web service and get back the config file for their system? We > >could make this an ExecStartPre for the thermald.service. Upside: we > >aren't shipping closed-source binaries but getting the advantage from > >them. Downside: this would mean thermald wouldn't be started until > >after the network was reachable. I suspect we could establish some > >fallback cases though. > > > >That said, given the rest of the comments on this ticket, I'm not sure > >we want to approve thermald for default operation on Fedora 32. It > >sounds as though it causes serious performance issues on many systems. > > So what Christian and Benjamin (the feature owners) have failed to > mention in this thread AFAICT is that part of the plan is to ship a > database with thermald with pre-extracted info for various models > (where we know that thermald is beneficial). > > With the pre-extracted info being matched to the laptop based on > DMI strings (the extracted info already contains DMI match info). > Note this is currently still being decided upon, but my latest > knowledge on this is that this is the plan. > > Given the reports of thermald sometimes being anything but helpful > and thermald not being very useful without the info, I guess we may > want to make it so that thermald only runs if pre-extracted info > is present for the device model we are running on. The change page is compatible with this description… It says > For optimal performance a per-model thermald configuration should > be created, this can either be done by using dptfxtract (available > from rpmfusion) or we could ship static configuration files for a > set of known models. At least I read it in the way that the "automatic" way with dptfxtract would be the main way, and the static configuration just a fallback. If static configuration is needed, then this would most likely be a lot of work and a precondition for making thermald a default. Or maybe, if thermald was made to exit quickly and cleanly if the configuration was not available, we could turn it "on", even though it would do nothing in the majority of cases until the configuration sets have been gathered. It sounds like the Change is still in flux. If it is to be accepted, it should describe the plan and the tradeoffs clearly. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
