Hey thanks for the feedback! I agree this seems to be from processing the interrupts rather than the touchpad itself.
One problem I had was to keep motion consistent between tests this is why I went for resting a finger on the touchpad and peak power draw from moving. I think you are right however measuring total consumption rather than rate would be better.
To clarify “just touching” is me resting a finger on the touchpad and the additional power draws mentioned above are constant rather than just spikes.
I did some further testing only in Windows to remove Linux variables.
When using the touchpad vs an optical USB mouse the touchpad is on average using 0.9 watts more doing the same task.
I considered doing a total consumption comparison but the duration needed to get some reasonable numbers would be longer than is physically comfortable.
Just an observation …
I disabled 3 cpu cores in the bios and noticed that as a result powertop now only shows roughly 25% of the wake up counts when using the touchpad.
I was curious to see if this was an issue with 12th gen as well. On Arch running Linux 6.0.7-arch1-1, I get the following on my system between doing nothing and holding my finger on the touchpad measuring with turbostat:
So, maybe someone with a Ryzen 6000 laptop can chime, but with my curiousity piqued, I also decided to test with my old 4800H PF5NU1G (running the same 6.0.7-arch1-1 kernel):
I noticed the increase in CPU pakage power is substantially different to the increase in total system draw however the psys power domain (which also adds the PCH and eDRAM consumption AFAIK) is much more reflective of the change. Perhaps this is more about the PCH than CPU package?
Not a framework laptop, but Googling led me here as I am having this issue in Arch on a Dell G5 with an i7-10750H cpu. Same symptoms as above, verified with turbostat. ~1.25w idle and ~2w just moving the mouse. ~1.5w just touching the touchpad…
Edit: Can confirm that I get better battery life and lower powertop system usage on both Fedora and NixOS compared to Arch on this specific laptop… So unfortunately I’ll have to use something other than Arch on this laptop for now
in Arch ~13-15 idle - 16-20w browsing the web (even a live ISO)
in Fedora or NixOS ~7.5w idle and 10-13w browsing the web so the difference is significant.
I think i have part of the reason why this is happening. I looked at this using fedora 37, and it seems the gpio interrupt is pinned to one core, and the i2c interrupts are pinned to a separate core. This means every time the touchpad fires an interrupt, both a high performance and efficiency core cluster have to wake up to service the touchpad! And these are probably not even in the same cluster, so lots of cache evictions etc might be happening as both core clusters power on and off and caches are cleared and filled.
What core type are TP interrupts handled by?
The second idea was to investigate what core the interrupts are handled by:
First you can look at the Cores on the system to map them to E or P cores. The E cores will have lower frequencies when looked at using:
lscpu --all --extended
The second thing was to find out what cores the interrupts were handled by:
And move the touchpad, you will see which core the touchpad interrupts are increasing on both.
However the PIXA GPIO interrupt is pinned to a high performance core, but the i2c-designware interrupt is pinned to an efficiency core.
I replicate this on EndeavourOS (Arch), Zorin (Ubuntu), and a Fedora live USB environment. My dstat readouts closely resemble those posted by others above. EndeavourOS is somewhat worse, and Fedore is somewhat less-terrible. On Endeavour, a USB mouse throws about half as many interrupts as the trackpad; I didn’t think to test this on the other OS’s.
I seem to be seeing the same thing - the PIXA interrupt is going HAM on my first (P) core.
Which identifier does one pass to SMP Affinity from the following? I understand that the e cores are the second block, however what is the identifier? Its currently set to 00c0 for btoh, and the smp_affinity_list set to 6-7
and checking if the numbers increase in the same column if using the touchpad.
I don’t think this is the final solution. As I understand from the thread, the number of generated interrupts is still too high. But this workaround is apparently better than nothing.
the large number of interrupts generated are probably from the i2c controller on the SOC, as each physical interrupt requires the CPU to transfer multiple bytes. A more optimized Linux kernel driver may be able to fix this.
Is there anyone here who’s willing to report this to the kernel folks?
Thanks everybody for the large amount of research that has gone into this.
From reading I understand that pinning interrupts to a certain core is a workaround that some people test with, but the process raises a few questions for me. I hope someone can shed a light here
Why only pinning the designware.2 interrupts? On my 11th Gen I see designware.{0,1,2} interrupts listed in /proc/interrupts.
What are the other 2 for?
Why pinning to CPU 2?
When I execute lscpu --all --extended multiple times over a range of a few minutes I see different cores with a high frequency - including CPU2. According to @Kieran_Levin the high frequency is how to recognize a P core, but if the E vs P core is not constant, the pinning ends up to be a hit & miss, no?
Is there a way to dedicate a CPU as E/P when on battery?
Why not pinning the PIXA interrupts too? Just to be explicit that both interrupts are actually handled by the same CPU.
