There will be another patch added soon, perhaps of interest to those using hardware p-states (speed shift). Speed shift is extremely sensitive and clock speeds (and voltages) can change by a large amount with low amount of utilisation changes, this also has an impact on temperatures.
I spent some days diagnosing what I felt was odd temperatures, and discovered a few problems, one which seems to be a bug that has been known about for years where there can be duplicated rrd processes causing extra cpu usage, the other one which I have patched.
So the stock behaviour for monitoring the temperature of the CPU and chipset is the PHP based RRD script will poll sysctl for the values, this script on my unit was temporarily increasing temperatures in excess of 10C, sometimes close to 20C, the temperature would shoot up for less than a second during the poll. and then drop back down again so to me it was not realistic.
The patch is combined with a command added to the cron, the command will poll the values directly using the shell and then save them to a temporary text dump, the patch modifies the RRD code so it simply reads the value from the text dump instead of doing its own direct poll.
This method uses no extra code overhead, so has a much lower impact on temperatures which means the polled value will more represent the average temperature the unit is running at.
Here is some graphs showing the change.
One of them is a CPU usage graph which highlights the bug with RRD gradually using more CPU cycles over time, if I diagnose this fully I will report it to the developers. This was having a impact on the plotted temperatures.
One graph over the same time period as the CPU graph shows the affect on plotted temperature from the RRD script bug, and the far right of that graph is after I patched the system.
There is also a graph over a shorter time period which shows the before and after from the change.
The plotted temperatures are now in line with what they were when running Windows.