CPU策略学习：interactive策略的优点和缺点

CPU策略学习：interactive策略的优点和缺点

我相信，研究CPU策略的人，经常会听别人说，或者自己说：每种策略都有好有不足，性能和功耗不能兼顾，性能好的功耗就大，为省功耗就会牺牲性能。

真是这样吗？

即使是真的，为什么这么说呢？？

下面我们从interactive策略，学习过程中，发现该策略的优点和不足之处，想想改进的方法，然后来琢磨这些老生常谈

主要特点：

升频幅度：大

升频速度：快

升频准度：一般

降频幅度：大

降频速度：一般

降频准度：一般

准度，是指在一次调频后，能否维持该频率在一段时间内是最适合系统当前负载

准度好，表示经过一次调频，系统在某个频率点运行一定时间，调频次数少

准度差，表示经过一次调频，系统会很快再次调频，调频次数多

至于对上诉特点的解释，前篇博文有结合实际代码分析，参看CPU 策略学习：interactive分析，结合代码

除了上面的特点，该策略还有一个特别突出的问题

由于这个策略是基于一个定时器，不断地计算系统在一个timer期间的负载情况，得出负载值后，根据一些算法，判定是否调频，如何调频

所以，这个timer的周期大小就很关键，一个周期内的平均值能否真实地反应出系统的频率需求，而且，该算法是根据当前时刻之前的一个timer周期的结果，来决定下一个周期系统的频率，也就是说，用之前的需求，猜测下一周期的需求；可以想象的到，对于系统而言，这两个周期的需求可能完全不同，这样的算法就会显得“自作聪明”，“自作多情”；而且在对系统由低负载到高负载的一小段时间（一个timer周期大小） 内，系统会以低频跑高负载任务。

典型的场景有：

input (touch keypad)

music play

local vedio play

这些场景一般不用系统跑高频，只需要中低频率即可，但是不能够迅速响应系统的需求

对于input的场景，android开发代码有进行考虑，这里也分析下

input系统的注册，会注册“device” 和“handlers”，在bus目录下，input系统为支持一个中断多个服务接口，用一个链表来支持handler的存储，在需要input响应时，触发的设备，只需要调用input提供的注册接口，就可以在handlers下面添加一个句柄。

input_register_handler(&cpufreq_interactive_input_handler);

static struct input_handler cpufreq_interactive_input_handler = {
	.event          = cpufreq_interactive_input_event,
	.connect        = cpufreq_interactive_input_connect,
	.disconnect     = cpufreq_interactive_input_disconnect,
	.name           = "cpufreq_interactive",
	.id_table       = cpufreq_interactive_ids,
};

在handler方法集中，event方法用于响应具体事件的到来，connect用于把句柄和input系统连接

static void cpufreq_interactive_input_event(struct input_handle *handle,
					    unsigned int type,
					    unsigned int code, int value)
{
	if (input_boost_val && type == EV_SYN && code == SYN_REPORT) {
		trace_cpufreq_interactive_boost("input");
		cpufreq_interactive_boost();
	}
}

这里的判断条件有两个方面：

1.input_boost_val是给用户接口的全局变量，可以通过设备节点随时开关

2.type == EV_SYN && code == SYN_REPORT标志的是input_sync的动作，包括press和release两个动作的sync

满足这两个条件，就会进入cpufreq_interactive_boost

cpufreq_interactive_boost：顾名思义，就是interactive对突发任务的处理。突发的任务就是系统在没有任务情况下，突然短时间有很高的需求，而且可能这个需求很短暂，需要系统随时响应，等不了timer判断好了后决定。场景有input music local vedio

static void cpufreq_interactive_boost(void)
{
	int i;
	int anyboost = 0;
	unsigned long flags;
	struct cpufreq_interactive_cpuinfo *pcpu;

	spin_lock_irqsave(&up_cpumask_lock, flags);

	for_each_online_cpu(i) {
		pcpu = &per_cpu(cpuinfo, i);
		//核心代码：如果比hispeed_freq低的频率，立刻提高到hispeed_freq

if (pcpu->target_freq < hispeed_freq) {
			pcpu->target_freq = hispeed_freq;
			cpumask_set_cpu(i, &up_cpumask);
			pcpu->target_set_time_in_idle =
				get_cpu_idle_time_us(i, &pcpu->target_set_time);
			pcpu->hispeed_validate_time = pcpu->target_set_time;
			anyboost = 1;
		}

		/*
		 * Set floor freq and (re)start timer for when last
		 * validated.
		 */

		pcpu->floor_freq = hispeed_freq;
		pcpu->floor_validate_time = ktime_to_us(ktime_get());
	}

	spin_unlock_irqrestore(&up_cpumask_lock, flags);

	if (anyboost)
		wake_up_process(up_task);//升频是优先级很高的栈任务，wake_up后,whie(1)立刻运行起来，系统马上升频
}

这个策略总体来讲，还不错，调频降频比较大胆冒进，在性能上有优越性，但是在频率切换上有很多需要完善的