On Thu, Jul 2, 2020 at 4:53 AM Benjamin Berg <bberg@xxxxxxxxxx> 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 <rjones@xxxxxxxxxx>
> 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@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
Jared Dominguez (he/him)
Laptop/Desktop Hardware Enablement ManagerRHEL Workstation Engineering
_______________________________________________ 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
