Bug 70941

Summary:	'powersave' performance excessively slow on Dell Venue 8 Pro (Baytrail tablet)
Product:	Power Management	Reporter:	Adam Williamson (adamw)
Component:	cpufreq	Assignee:	Dirk Brandewie (dirk.brandewie)
Status:	CLOSED PATCH_ALREADY_AVAILABLE
Severity:	high	CC:	bugzilla, dirk.brandewie, lenb, tianyu.lan, tomi
Priority:	P1
Hardware:	i386
OS:	Linux
Kernel Version:	3.14rc3	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	Patch to fix performance regresion

Description Adam Williamson 2014-02-21 08:53:02 UTC

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.

Comment 1 Dirk Brandewie 2014-02-21 15:04:01 UTC


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

Comment 2 Dirk Brandewie 2014-02-24 19:18:27 UTC

Created attachment 127321 [details]
Patch to fix performance regresion

Please try the attached patch.  Without the change to the default setpoint.

Comment 3 Adam Williamson 2014-02-26 04:25:42 UTC

Looks good here. Built a kernel with this patch instead of the setpoint change, seems to perform fine, nothing exploded.

Comment 4 Tomas Janousek 2014-03-24 19:09:19 UTC

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?

Comment 5 Len Brown 2015-07-21 18:50:52 UTC

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