Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Thu, Jul 2, 2020 at 4:53 AM Benjamin Berg wrote: > On Wed, 2020-07-01 at 11:07 -0500, Michael Catanzaro wrote: > > So the last two times thermald was proposed (first as a F32 change > > proposal, then more recently to the Workstation WG) it was rejected on > > the grounds that it was not useful without dptfxtract installed. Now > > it's clear that everybody was mistaken about that, so seems it makes > > sense to reconsider. > > > > I have a couple questions. First, why is thermal management occurring > > in userspace? Can you please provide a technical explanation as to why > > the kernel is not the right place for this code? > > The thermal daemon has a bit of information: > > https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon > > It lists the following reasons: > * A short time to market > * Proactively controlled temperature > * Use of existing kernel infrastructure > * A defined architecture, which can be easily enhanced. > > In general, I don't see a problem with moving some logic into > userspace. It is not like the kernel is in a much better position to > make decisions. It only is closer to the hardware from an architectural > point of view and will only be in a better position if decisions must > not be delayed (e.g. protecting the hardware from overheating). > It's also a design meant to mimic Intel's Windows implementation, which allows for more advanced control based on workloads as desired in some of the more advanced flavors of DPTF (i.e. not Passive). > On Wed, Jul 1, 2020 at 11:53 am, Richard W.M. Jones > > wrote: > > > Is there some background about why dptfxtract is proprietary? (I see > > > that it's a program provided by Intel.) Is it just because no one's > > > done the work to make a free equivalent or does it require some > > > secret/patented/whatever knowledge to work? > > > > I'm also interested in this question. In particular, since thermald and > > dptfxtract are both the same upstream, it seems really hostile to the > > open source community for thermald to perform better if you have this > > extra proprietary portion of the project installed. > > My interpretation is that, Intel is trying to protect their IP around > thermal management and how DPTF works in particular. > Some additional context: When I was at Dell, I helped push for Intel to start supporting more DPTF features on Linux in order for Dell to be able to ship Linux on our more thermally constrained mechanical designs. DPTF Passive 1.0 (and some other stuff? can't remember the state back then) was already supported by thermald. Due to Intel's IP concerns, we couldn't get an open source implementation of the userspace logic used for other DPTF policies, but we could get someone at Intel to write dptfxtract, which tries to make a smart interpretation of some of the otherwise unsupported (on Linux) tables and output tables that are usable on Linux. Unfortunately, I cannot share details of Intel's IP concerns due to NDA I'm still beholden to. Note however that dptfxtract wasn't meant to be a be-all-end-all but rather a solution to the immediate problem of Linux being behind in support DPTF, which is widely implemented by Intel-based laptops in the market. It was released with the understanding that it's an imperfect solution, and that is part of why it was made to be an _optional_ addition to thermald. I can't speak for Intel, but I trust that they'll come forward when they are ready to release to the community better Linux solutions for supporting DPTF. I suspect that would largely come as additions to thermald. > So, for me, the hostile part here is that we are dealing with a > hardware platform that contains components for which the manufacturer > is not willing to provide proper documentation. > > The thermald upstream on the other hand is trying to provide the best > possible experience while working under these imposed constraints. So > thermald will use all the information that it can get, and dptfxtract > allows exporting proprietary information encoded in the DPTF related > data stored in ACPI. > > Benjamin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > -- Jared Dominguez (he/him) Laptop/Desktop Hardware Enablement Manager RHEL Workstation Engineering ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Wed, Jul 01, 2020 at 10:36:59AM +0200, Benjamin Berg wrote: > On Tue, 2020-06-30 at 17:48 +0200, Vitaly Zaitsev via devel wrote: > > On 30.06.2020 15:25, Ben Cotton wrote: > > > Better thermal management and peak performance on Intel CPUs by > > > including thermald in the default install. > > > > Good, but thermald is absolutely useless without configs. Configs can be > > extracted from DPTF ACPI tables only with *proprietary* dptfextract utility. > > But, this is not true in general and we can expect further improvements > in the near future. It will not help in all situations, but there are > situations where users will see improved performance. One example of > this is for example an improved peak-performance on pre-Kabylake > systems (I am looking into finding further examples). > > > So, it is true that thermald will throw around quite a few warnings at > startup (it seems to warn about anything it probes and cannot find). > But that does not imply that it is always useless. It does for example > use information from the PPCC tables even if it does not have any > configuration. These power limits are exported by the kernel in > /sys/bus/pci/devices/*/power_limits/. That is worrying. We already have plenty of services which spam the logs with pointless warnings, leading to bad UX. I think fixing this should be a prerequisite to enabling by default. > Also, some reverse engineering work has been happening. This means that > it is possible to improve thermald to get at least some of the benefits > of a DPTF based configuration without needing dptfxtract. This is > currently still work in progress, however, upstream is planning to > merge this work once it has been cleaned up sufficiently. > > i.e. at this point we can fully expect to get improved thermal > management based on the DPTF tables without dptfxtract. So... could we arrange it so that thermald only runs if there's actually a benefit from it running? E.g. exit quietly if it realizes it cannot do anything useful for the hardware present? > > Also Fedora cannot ship extracted by dptfextract configs due to their > > legal status. > > The idea to ship those configurations separately has been dropped from > the proposal. The proposal says "Proposal owners: - Include the thermald package in the default Workstation install". Do you want it be enabled by default? If yes, the proposal should say that. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Wed, 2020-07-01 at 11:07 -0500, Michael Catanzaro wrote: > So the last two times thermald was proposed (first as a F32 change > proposal, then more recently to the Workstation WG) it was rejected on > the grounds that it was not useful without dptfxtract installed. Now > it's clear that everybody was mistaken about that, so seems it makes > sense to reconsider. > > I have a couple questions. First, why is thermal management occurring > in userspace? Can you please provide a technical explanation as to why > the kernel is not the right place for this code? The thermal daemon has a bit of information: https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon It lists the following reasons: * A short time to market * Proactively controlled temperature * Use of existing kernel infrastructure * A defined architecture, which can be easily enhanced. In general, I don't see a problem with moving some logic into userspace. It is not like the kernel is in a much better position to make decisions. It only is closer to the hardware from an architectural point of view and will only be in a better position if decisions must not be delayed (e.g. protecting the hardware from overheating). On Wed, Jul 1, 2020 at 11:53 am, Richard W.M. Jones > wrote: > > Is there some background about why dptfxtract is proprietary? (I see > > that it's a program provided by Intel.) Is it just because no one's > > done the work to make a free equivalent or does it require some > > secret/patented/whatever knowledge to work? > > I'm also interested in this question. In particular, since thermald and > dptfxtract are both the same upstream, it seems really hostile to the > open source community for thermald to perform better if you have this > extra proprietary portion of the project installed. My interpretation is that, Intel is trying to protect their IP around thermal management and how DPTF works in particular. So, for me, the hostile part here is that we are dealing with a hardware platform that contains components for which the manufacturer is not willing to provide proper documentation. The thermald upstream on the other hand is trying to provide the best possible experience while working under these imposed constraints. So thermald will use all the information that it can get, and dptfxtract allows exporting proprietary information encoded in the DPTF related data stored in ACPI. Benjamin signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Wed, Jul 1, 2020 at 5:49 pm, Vitaly Zaitsev via devel wrote: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/D4FVY3LLMNGUKNUOEIDXNOOAD577W5XN/ None of the comments in that thread support the claim that we cannot ship configuration files generated by dptfxtract. (That said, as the current version of the change proposal doesn't propose doing so, it's a bit of a moot point.) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
So the last two times thermald was proposed (first as a F32 change proposal, then more recently to the Workstation WG) it was rejected on the grounds that it was not useful without dptfxtract installed. Now it's clear that everybody was mistaken about that, so seems it makes sense to reconsider. I have a couple questions. First, why is thermal management occurring in userspace? Can you please provide a technical explanation as to why the kernel is not the right place for this code? On Wed, Jul 1, 2020 at 11:53 am, Richard W.M. Jones wrote: Is there some background about why dptfxtract is proprietary? (I see that it's a program provided by Intel.) Is it just because no one's done the work to make a free equivalent or does it require some secret/patented/whatever knowledge to work? I'm also interested in this question. In particular, since thermald and dptfxtract are both the same upstream, it seems really hostile to the open source community for thermald to perform better if you have this extra proprietary portion of the project installed. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On 30.06.2020 22:38, Michael Catanzaro wrote: > Any references would be very interesting, thanks. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/D4FVY3LLMNGUKNUOEIDXNOOAD577W5XN/ -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On 01/07/2020 11:53, Richard W.M. Jones wrote: On Tue, Jun 30, 2020 at 10:30:21AM -0400, Owen Taylor wrote: So, this was discussed quite a bit in https://pagure.io/fedora-workstation/issue/71 and the conclusion that the Workstatopn Working Group came to 3 months ago was that we didn't want to do this. We basically understood that main way of using thermald was to use the proprietary dptfxtract tool to extract a profile from ACPI - and as such, thermald wasn't something Fedora should install by default. This functionality can't be properly integrated into Fedora and "just work" for users if it requires a proprietary tool and extra steps. Is there some background about why dptfxtract is proprietary? (I see that it's a program provided by Intel.) Is it just because no one's done the work to make a free equivalent or does it require some secret/patented/whatever knowledge to work? There is work being done to make thermald read the tables from the BIOS directly, including supporting more advanced features that dptfxtract doesn't. More details here: https://mjg59.dreamwidth.org/54923.html and PR for thermald: https://github.com/intel/thermal_daemon/pull/224 Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Tue, Jun 30, 2020 at 10:30:21AM -0400, Owen Taylor wrote: > So, this was discussed quite a bit in > https://pagure.io/fedora-workstation/issue/71 and the conclusion that > the Workstatopn Working Group came to 3 months ago was that we didn't > want to do this. We basically understood that main way of using > thermald was to use the proprietary dptfxtract tool to extract a > profile from ACPI - and as such, thermald wasn't something Fedora > should install by default. This functionality can't be properly > integrated into Fedora and "just work" for users if it requires a > proprietary tool and extra steps. Is there some background about why dptfxtract is proprietary? (I see that it's a program provided by Intel.) Is it just because no one's done the work to make a free equivalent or does it require some secret/patented/whatever knowledge to work? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Tue, 2020-06-30 at 17:48 +0200, Vitaly Zaitsev via devel wrote: > On 30.06.2020 15:25, Ben Cotton wrote: > > Better thermal management and peak performance on Intel CPUs by > > including thermald in the default install. > > Good, but thermald is absolutely useless without configs. Configs can be > extracted from DPTF ACPI tables only with *proprietary* dptfextract utility. But, this is not true in general and we can expect further improvements in the near future. It will not help in all situations, but there are situations where users will see improved performance. One example of this is for example an improved peak-performance on pre-Kabylake systems (I am looking into finding further examples). So, it is true that thermald will throw around quite a few warnings at startup (it seems to warn about anything it probes and cannot find). But that does not imply that it is always useless. It does for example use information from the PPCC tables even if it does not have any configuration. These power limits are exported by the kernel in /sys/bus/pci/devices/*/power_limits/. Also, some reverse engineering work has been happening. This means that it is possible to improve thermald to get at least some of the benefits of a DPTF based configuration without needing dptfxtract. This is currently still work in progress, however, upstream is planning to merge this work once it has been cleaned up sufficiently. i.e. at this point we can fully expect to get improved thermal management based on the DPTF tables without dptfxtract. > Also Fedora cannot ship extracted by dptfextract configs due to their > legal status. The idea to ship those configurations separately has been dropped from the proposal. Benjamin signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Tue, Jun 30, 2020 at 9:40 pm, Vitaly Zaitsev via devel wrote: The legal status of the extracted tables was discussed a few months ago with members of the Fedora legal team. You can check archives. I tried: https://lists.fedoraproject.org/archives/search?mlist=legal%40lists.fedoraproject.org=dptfxtract And: https://lists.fedoraproject.org/archives/search?mlist=legal%40lists.fedoraproject.org=thermald Any references would be very interesting, thanks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Tue, 30 Jun 2020 at 16:14, Jared Dominguez wrote: > > > > On Tue, Jun 30, 2020 at 3:41 PM Vitaly Zaitsev via devel > wrote: >> >> On 30.06.2020 19:43, Hans de Goede wrote: >> > That is the first time I have heard that. Do you have a source for that ? >> >> https://github.com/intel/dptfxtract - no sources, only proprietary binaries. >> >> The legal status of the extracted tables was discussed a few months ago >> with members of the Fedora legal team. You can check archives. > > > Regardless of the legality of tables output from dptfxtract, that doesn't > really address the fact that thermald, as is in Fedora 32 today (version > 1.9.1 from December) doesn't have dptfxtract (nor do later versions bundle > it) and results in an improvement in thermal behavior on supported systems > without any thermal tables in /etc/thermald. > I am going to say citation is needed here as much as Vitaly's comments. What systems does it work with? How does it work on these systems? What systems does it not work on? Are the various problems from the last time this was discussed to death https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/D4FVY3LLMNGUKNUOEIDXNOOAD577W5XN/ been dealt with? -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Tue, Jun 30, 2020 at 3:41 PM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 30.06.2020 19:43, Hans de Goede wrote: > > That is the first time I have heard that. Do you have a source for that ? > > https://github.com/intel/dptfxtract - no sources, only proprietary > binaries. > > The legal status of the extracted tables was discussed a few months ago > with members of the Fedora legal team. You can check archives. > Regardless of the legality of tables output from dptfxtract, that doesn't really address the fact that thermald, as is in Fedora 32 today (version 1.9.1 from December) doesn't have dptfxtract (nor do later versions bundle it) and results in an improvement in thermal behavior on supported systems without any thermal tables in /etc/thermald. -- Jared Dominguez (he/him) Laptop/Desktop Hardware Enablement Manager RHEL Workstation Engineering ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On 30.06.2020 19:43, Hans de Goede wrote: > That is the first time I have heard that. Do you have a source for that ? https://github.com/intel/dptfxtract - no sources, only proprietary binaries. The legal status of the extracted tables was discussed a few months ago with members of the Fedora legal team. You can check archives. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
Hi, On 6/30/20 5:48 PM, Vitaly Zaitsev via devel wrote: On 30.06.2020 15:25, Ben Cotton wrote: Better thermal management and peak performance on Intel CPUs by including thermald in the default install. Good, but thermald is absolutely useless without configs. Configs can be extracted from DPTF ACPI tables only with *proprietary* dptfextract utility. Also Fedora cannot ship extracted by dptfextract configs due to their legal status. That is the first time I have heard that. Do you have a source for that ? Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Tue, Jun 30, 2020 at 12:10 PM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 30.06.2020 17:57, Jared Dominguez wrote: > > Something that needs to be cleared up here: thermald has existed for the > > better part of a decade and long before dptfxtract existed. > > Thermald will not work without config being installed. > > You can remove all configs from /etc/thermald and try to start systemd > unit. It will shutdown immediately. > (BTW, for some context, I was directly involved in the discussion at Dell -- when I was one of the Linux leads there -- that resulted in someone at Intel creating dptfxtract as a temporary solution until Intel's open source folks could find a better solution for supporting DPTF Active policies. I started at Red Hat in April and asked Benjamin to revisit this topic since thermald is still incredibly useful without dptfxtract. Plus, a former colleague at Dell noticed some Fedora users having issues that are solved by using thermald (even without dptfxtract).) thermald predates dptfxtract existing. dptfxtract exists to dynamically pull OEM platform specific configs for only certain kinds of newer DPTF tables. thermald still runs on most other Intel systems. For example, my system only has /etc/thermald/thermal-cpu-cdev-order.xml inside /etc/thermald, and that one xml file only contains this: """ rapl_controller intel_pstate intel_powerclamp cpufreq Processor """ I wouldn't consider the above file legally dubious. After enabling thermald, it's definitely running: $ rpm -q thermald thermald-1.9.1-2.fc32.x86_64 $ systemctl status thermald ● thermald.service - Thermal Daemon Service Loaded: loaded (/usr/lib/systemd/system/thermald.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2020-06-30 13:01:50 EDT; 12min ago Main PID: 296760 (thermald) Tasks: 2 (limit: 18941) Memory: 2.5M CPU: 70ms CGroup: /system.slice/thermald.service └─296760 /usr/sbin/thermald --no-daemon --dbus-enable -- Jared Dominguez (he/him) Laptop/Desktop Hardware Enablement Manager RHEL Workstation Engineering ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On 30.06.2020 17:57, Jared Dominguez wrote: > Something that needs to be cleared up here: thermald has existed for the > better part of a decade and long before dptfxtract existed. Thermald will not work without config being installed. You can remove all configs from /etc/thermald and try to start systemd unit. It will shutdown immediately. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On Tue, Jun 30, 2020 at 11:49 AM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 30.06.2020 15:25, Ben Cotton wrote: > > Better thermal management and peak performance on Intel CPUs by > > including thermald in the default install. > > Good, but thermald is absolutely useless without configs. Configs can be > extracted from DPTF ACPI tables only with *proprietary* dptfextract > utility. > > Also Fedora cannot ship extracted by dptfextract configs due to their > legal status. > Something that needs to be cleared up here: thermald has existed for the better part of a decade and long before dptfxtract existed. dptfxtract exists to handle certain platforms that use DPTF Active. thermald supports many, many more platforms than that without the need for any closed-source tools. Additionally, with code that is queued in a thermald branch, we may not need dptfxtract for any use cases soon. -- Jared Dominguez (he/him) Laptop/Desktop Hardware Enablement Manager RHEL Workstation Engineering ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
On 30.06.2020 15:25, Ben Cotton wrote: > Better thermal management and peak performance on Intel CPUs by > including thermald in the default install. Good, but thermald is absolutely useless without configs. Configs can be extracted from DPTF ACPI tables only with *proprietary* dptfextract utility. Also Fedora cannot ship extracted by dptfextract configs due to their legal status. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
So, this was discussed quite a bit in https://pagure.io/fedora-workstation/issue/71 and the conclusion that the Workstatopn Working Group came to 3 months ago was that we didn't want to do this. We basically understood that main way of using thermald was to use the proprietary dptfxtract tool to extract a profile from ACPI - and as such, thermald wasn't something Fedora should install by default. This functionality can't be properly integrated into Fedora and "just work" for users if it requires a proprietary tool and extra steps. After seeing the submission this morning, we talked to Benjamin Berg on our call today, and he said that the main reason that he submitted this despite the earlier discussion was that he recently was told by an OEM that when run without a profile it made a big difference on some of their models. We asked Benjamin if he could provide more details about what models and the difference in performance - he will go back to the OEM and ask for more information, and we'll discuss this again at our call next week. - Owen On Tue, Jun 30, 2020 at 9:27 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/ThermalManagementWS > > == Summary == > Better thermal management and peak performance on Intel CPUs by including > thermald in the default install. > > == Owner == > * Name: [[User:benzea| Benjamin Berg]] > * Email: bb...@redhat.com > > * Name: [[User:ckellner| Christian J. Kellner]] > * Email: ckell...@redhat.com > > * Product: Workstation > * Responsible WG: Workstation > > > == Detailed Description == > > Modern Intel-based systems provide sensors and methods to monitor and control > temperature of its CPUs. The Thermal daemon will use those sensors to monitor > the temperature and use the best available method to keep the CPU in the > right temperature envelop. On certain systems this is needed to reach the > maximal performance. thermald will for example use the PPCC power table to > set power limits (when available, see for example > https://www.mail-archive.com/kernel-packages@lists.launchpad.net/msg411614.html). > This is for example the case on Ice Lake, where thermald can increase the > performance of the out-of-the-box behaviour of Fedora. > > Not strictly necessary, but *further* improvements can be achieved by using > per-model thermald configurations. The most straight forward way of using > those is for the user to install dptfxtract (available from rpmfusion). At > least parts of what dptfxtract can already do may be integrated into thermald > in the future thanks to the reverse engineering work done by Matthew Garret > (see https://github.com/intel/thermal_daemon/tree/mg_patches_test, > https://github.com/intel/thermal_daemon/pull/224). Should the reverse > engineering effort be merged, or if the user installs dptfxtract, then they > can expect a performance boost on some machines. > > Theoretically one could ship appropriate per-machine configurations as a > separate package (or inside thermald). However, this is not part of the > proposal for a number of reasons: > 1. It is not clear how the configuration data can be collected > 2. We do not currently have an implementation to load such configuration data > 3. This may become obsolete with if the reverse-engineering effort continues > and is merged (or picked up by Fedora) > > For a more details explanation please consult Intel's > [https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon > introduction] to thermald. > > == Benefit to Fedora == > Better out-of-the-box experience due to improved cooling methods and > performance on Intel systems. This affects many modern laptops (e.g. the Ice > Lake platform). On affected machines, Fedora would continue to have poorer > performance compared to other distributions. > > == Scope == > * Proposal owners: > - Include the thermald package in the default Workstation install > > * Other developers: N/A (not a System Wide Change) > * Release engineering: > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > N/A (not a System Wide Change) > > == How To Test == > > 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. > > == User Experience == > - Better performance on certain hardware > - Better cooling of CPUs on certain hardware > > == Dependencies == > N/A (not a System Wide Change) > > == Contingency Plan == > * Contingency mechanism: Don't ship package by default > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? N/A > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an
Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 09:25 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/ThermalManagementWS > > == Summary == > Better thermal management and peak performance on Intel CPUs by > including > thermald in the default install. I have strong feeling that this has been already submitted before. https://fedoraproject.org/w/index.php?title=Changes%2FThermalManagementWS=revision=580846=557200 Sadly the diff is so small that I don't think change owners really read feedback from the mailing list. Neither it incorporated "Feedback" section in the proposal. > == Owner == > * Name: [[User:benzea| Benjamin Berg]] > * Email: bb...@redhat.com > > * Name: [[User:ckellner| Christian J. Kellner]] > * Email: ckell...@redhat.com > > * Product: Workstation > * Responsible WG: Workstation > > > == Detailed Description == > > Modern Intel-based systems provide sensors and methods to monitor and > control temperature of its CPUs. The Thermal daemon will use those > sensors > to monitor the temperature and use the best available method to keep > the > CPU in the right temperature envelop. On certain systems this is > needed to > reach the maximal performance. thermald will for example use the PPCC > power > table to set power limits (when available, see for example > > https://www.mail-archive.com/kernel-packages@lists.launchpad.net/msg411614.html > ). > This is for example the case on Ice Lake, where thermald can increase > the > performance of the out-of-the-box behaviour of Fedora. > > Not strictly necessary, but *further* improvements can be achieved by > using > per-model thermald configurations. The most straight forward way of > using > those is for the user to install dptfxtract (available from > rpmfusion). At > least parts of what dptfxtract can already do may be integrated into > thermald in the future thanks to the reverse engineering work done by > Matthew Garret (see > https://github.com/intel/thermal_daemon/tree/mg_patches_test, > https://github.com/intel/thermal_daemon/pull/224). Should the reverse > engineering effort be merged, or if the user installs dptfxtract, > then they > can expect a performance boost on some machines. > > Theoretically one could ship appropriate per-machine configurations > as a > separate package (or inside thermald). However, this is not part of > the > proposal for a number of reasons: > 1. It is not clear how the configuration data can be collected > 2. We do not currently have an implementation to load such > configuration > data > 3. This may become obsolete with if the reverse-engineering effort > continues and is merged (or picked up by Fedora) > > For a more details explanation please consult Intel's [ > > https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon > introduction] to thermald. > > == Benefit to Fedora == > Better out-of-the-box experience due to improved cooling methods and > performance on Intel systems. This affects many modern laptops (e.g. > the > Ice Lake platform). On affected machines, Fedora would continue to > have > poorer performance compared to other distributions. I think the change page is missing information what exactly this daemon does if it is installed. > == Scope == > * Proposal owners: > - Include the thermald package in the default Workstation install I believe this won't do anything because the daemon won't be enabled. > * Other developers: N/A (not a System Wide Change) > * Release engineering: > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > N/A (not a System Wide Change) > > == How To Test == > > 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 if improvements are only visible when non-free software is installed - - what is the reason to ship it by default? > == User Experience == > - Better performance on certain hardware > - Better cooling of CPUs on certain hardware > > == Dependencies == > N/A (not a System Wide Change) > > == Contingency Plan == > * Contingency mechanism: Don't ship package by default > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? N/A > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77Q6wACgkQEV1auJxc
