@

【WALT】scale_exec_time() 程式碼詳解

程式碼版本：Linux4.9 android-msm-crosshatch-4.9-android12

程式碼展示

static inline u64 scale_exec_time(u64 delta, struct rq *rq)
{
	u32 freq;
	// ⑴ 將 CPU cycles 轉換為 CPU 當前頻率
	freq = cpu_cycles_to_freq(rq->cc.cycles, rq->cc.time);
	// ⑵ 歸一化 delta
	delta = DIV64_U64_ROUNDUP(delta * freq, max_possible_freq);
	delta *= rq->cluster->exec_scale_factor;
	delta >>= 10;

	return delta;
}

程式碼邏輯：

scale_exec_time() 函數用於給任務的執行時間 delta 進行歸一化。

為什麼歸一化？

EAS 主要針對異構 CPU 架構，如 Arm big.LITTLE，因為這種架構有不同效能和功耗的 CPU 核心，不同 CPU 的最大算力、最大頻率等都不同。假定一個任務在當前視窗中執行了 5ms，對不同頻率的兩個 CPU 來說，5ms 帶來的負載是截然不同的。

WALT 演演算法引入了一種類似權重的方法，根據 CPU 的頻率（frequency）和 最大每週期指令數（efficiency）來對任務的執行時間進行歸一化。
（注：此處 efficiency 的定義並不確定，在核心檔案中出現過這個定義。）

⑴ 將 CPU cycles 轉換為 CPU 當前頻率

freq = cpu_cycles_to_freq(rq->cc.cycles, rq->cc.time);

static inline u32 cpu_cycles_to_freq(u64 cycles, u64 period)
{
	return div64_u64(cycles, period);
}

在這裡 freq = rq->cc.cycles / rq->cc.time。其中，rq->cc.cycles 和 rq->cc.time 在函數 update_task_rq_cpu_cycles() 中更新：

static void
update_task_rq_cpu_cycles(struct task_struct *p, struct rq *rq, int event,
			  u64 wallclock, u64 irqtime)
{
	u64 cur_cycles;
	int cpu = cpu_of(rq);

	lockdep_assert_held(&rq->lock);

	if (!use_cycle_counter) {
		rq->cc.cycles = cpu_cur_freq(cpu);
		rq->cc.time = 1;
		return;
	}

	cur_cycles = read_cycle_counter(cpu, wallclock);

	/*
	 * If current task is idle task and irqtime == 0 CPU was
	 * indeed idle and probably its cycle counter was not
	 * increasing.  We still need estimatied CPU frequency
	 * for IO wait time accounting.  Use the previously
	 * calculated frequency in such a case.
	 */
	if (!is_idle_task(rq->curr) || irqtime) {
		if (unlikely(cur_cycles < p->cpu_cycles))
			rq->cc.cycles = cur_cycles + (U64_MAX - p->cpu_cycles);
		else
			rq->cc.cycles = cur_cycles - p->cpu_cycles;
		rq->cc.cycles = rq->cc.cycles * NSEC_PER_MSEC;

		if (event == IRQ_UPDATE && is_idle_task(p))
			/*
			 * Time between mark_start of idle task and IRQ handler
			 * entry time is CPU cycle counter stall period.
			 * Upon IRQ handler entry sched_account_irqstart()
			 * replenishes idle task's cpu cycle counter so
			 * rq->cc.cycles now represents increased cycles during
			 * IRQ handler rather than time between idle entry and
			 * IRQ exit.  Thus use irqtime as time delta.
			 */
			rq->cc.time = irqtime;
		else
			rq->cc.time = wallclock - p->ravg.mark_start;
		BUG_ON((s64)rq->cc.time < 0);
	}

	p->cpu_cycles = cur_cycles;

	trace_sched_get_task_cpu_cycles(cpu, event, rq->cc.cycles, rq->cc.time, p);
}

⑵ 歸一化 delta

1. delta = DIV64_U64_ROUNDUP(delta * freq, max_possible_freq);
   即 delta = delta * freq/max_possible_freq。

   freq 是當前 CPU 的頻率，由 ⑴ 計算而得：freq = rq->cc.cycles / rq->cc.time。

   max_possible_freq 就是 max(policy->cpuinfo.max_freq)。
   policy 可以淺顯地認為是簇號，如不同的 policy 指向小核簇、大核簇和超大核：

   • 對於擁有多個 CPU 的簇來說，頻率的計算在 sugov_update_shared() 中進行，簇內每個 CPU 的頻率都是一致的，因此一個簇會擁有一個當前頻率和一個最大頻率，即 policy->cpuinfo.max_freq；
   • 對於單個 CPU 來說，頻率的計算在 sugov_update_single() 中進行，它也會有一個最大頻率 policy->cpuinfo.max_freq。

   在執行該版本核心的 pixel 3xl 中，8 個 CPU 分為小核簇與大核簇，他們的最大頻率分別是 381 和 1024。

2. delta *= rq->cluster->exec_scale_factor;
   cluster->exec_scale_factor = 1024 * cluster->efficiency/max_possible_efficiency

   cluster->efficiency 可能指 執行任務的 CPU 的每週期指令數 (IPC)。

   max_possible_efficiency 可能指 系統中任何 CPU 提供的最大 IPC。
   這個值在裝置樹中給定，在執行該版本核心的 pixel 3xl 中，小核簇和大核簇的 max_possible_efficiency 分別是 1024 和 1740。

3. delta >>= 10;
   即 delta = delta / 1024。

將三句程式碼一起看，能得出一個等式：
\(delta\_s = delta\times\dfrac{curr\_freq}{max\_possible\_freq}\times\dfrac{cluster->efficiency}{max\_possible\_efficiency}\)

點選此處回到 WALT 入口函數 update_task_ravg()