I've noticed recent 3.14 kernels perform extremely sluggishly on my Venue 8 Pro (Baytrail-based tablet). Doing 'echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor' speeds things right up again: default is 'powersave'. Obviously performance will be faster, but powersave seems really egregiously slow. Just stuff like paging through console output at a VT is incredibly sluggish - I can run 'journalctl -b', hit End, and watch it draw one painful line at a time. The scaling_driver is 'intel_pstate' . I think pstate stuff may have been broken on baytrail for a while - I had to boot with intel_pstate=disable for a bit, and before that it may just not have been kicking in - which is probably why I didn't notice this until rc2 or so. The frequency range is 200MHz->1.6GHz with both 'powersave' and 'performance'. I'm not sure what's the best way to watch the scaling kick in, but using powertop or just spamming 'cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq' , it does seem to scale up rather faster with performance. Not sure what info is needed to help debug this, just ask and I'll provide.
commit fcb6a15c2e7e76d493e6f91ea889ab40e1c643a4 is the problem. I am working on a fix ATM. Lowering the setpoint for the PID should workaround the problem echo 90 > /sys/kernel/debug/pstate_snb/setpoint This will cost some power though. This also broke GregKH https://lkml.org/lkml/2014/2/19/626
Created attachment 127321 [details] Patch to fix performance regresion Please try the attached patch. Without the change to the default setpoint.
Looks good here. Built a kernel with this patch instead of the setpoint change, seems to perform fine, nothing exploded.
I'm having a similar issue on my ThinkPad T420 with i5-2520M on yesterdays master which has both fcb6a15c2e7e76d493e6f91ea889ab40e1c643a4 and e66c176837462928a05a135bbe16cdce70536d6e. Reverting both of them seems to fix things again. Shall I open a new issue?
shipped in Linux 3.15: commit f0fe3cd7e12d8290c82284b5c8aee723cbd0371a Author: Dirk Brandewie <dirk.j.brandewie@intel.com> Date: Thu May 29 09:32:23 2014 -0700 intel_pstate: Correct rounding in busy calculation