【WALT】WALT入口 update_task_ravg()

WALT算法在Linux内核中用于任务负载平均的计算。update_task_ravg()函数负责更新任务的周期、需求和预测需求等,涉及窗口开始时间判断、任务初始化、CPU繁忙时间更新等多个关键步骤。该函数在任务唤醒、执行、退出等时刻被调用,影响着任务调度策略。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

【WALT】WALT入口 update_task_ravg()

代码版本:Linux4.9 android-msm-crosshatch-4.9-android12

代码展示

void update_task_ravg(struct task_struct *p, struct rq *rq, int event,
						u64 wallclock, u64 irqtime)	{
	u64 old_window_start;
	
	// ⑴ 判断是否进入 WALT 算法
	if (!rq->window_start || sched_disable_window_stats ||
	    p->ravg.mark_start == wallclock)
		return;

	lockdep_assert_held(&rq->lock);

	// ⑵ 获取 WALT 算法中上一个窗口的开始时间
	old_window_start = update_window_start(rq, wallclock, event);

	// ⑶ 如果任务刚初始化结束,不进入 WALT 算法,进入 `done`
	if (!p->ravg.mark_start) {
		update_task_cpu_cycles(p, cpu_of(rq), wallclock);
		goto done;
	}

	// ⑷ 更新任务及 CPU 的 cycles
	update_task_rq_cpu_cycles(p, rq, event, wallclock, irqtime);
	// ⑸ 更新任务及 CPU 的 demand 及 pred_demand
	update_task_demand(p, rq, event, wallclock);
	// ⑹ 更新 CPU 的 busy time
	update_cpu_busy_time(p, rq, event, wallclock, irqtime);
	// ⑺ 更新任务的 pred_demand
	update_task_pred_demand(rq, p, event);

	// ⑻ 如果任务正在退出,进入 `done`
	if (exiting_task(p))
		goto done;

	// 两个系统自带的 tracepoint
	trace_sched_update_task_ravg(p, rq, event, wallclock, irqtime,
				rq->cc.cycles, rq->cc.time, &rq->grp_time);
	trace_sched_update_task_ravg_mini(p, rq, event, wallclock, irqtime,
				rq->cc.cycles, rq->cc.time, &rq->grp_time);

done:
	p->ravg.mark_start = wallclock;
	run_walt_irq_work(old_window_start, rq);
}

代码逻辑

WALT 算法以任务为主,当任务被唤醒、任务开始执行、任务停止执行、任务退出、窗口滚动、频率变化、任务迁移、经过一个调度tick、在中断结束时会调用update_task_ravg()

其中,窗口是 WALT 算法中的一个特殊的设定,将在 update_task_demand()update_cpu_busy_time() 中详细解释。

⑴ 判断是否进入 WALT 算法

在进入 WALT 算法后首先会判断当前任务所在的运行队列(runqueue)是否进行初始化,以及是否禁用 CPU 的窗口统计:if(!rq->window_start || sched_disable_window_stats...)。如果没有初始化,就不会记录窗口的开始时间,任务负载就无法进行计算。有几点需要注意:

  1. 该处是指 rq,而非 cfs->rq 或 rt->rq,即该处不区分实时任务或普通任务;
  2. 任务/CPU 窗口(sched_ravg_window)是自定义的,不同版本代码或不同设备中设置的窗口大小是不一样的,调整的位置也不尽相同。

然后会判断窗口开始时间是否更新:if(...p->ravg.mark_start == wallclock)。如果运行队列没有初始化,或禁用了 CPU 的窗口统计,或窗口开始时间没有更新,就会直接结束 WALT 算法。

⑵ 获取 WALT 算法中上一个窗口的开始时间

然后通过函数update_window_start()获取上一个窗口的开始时间,存在变量old_window_start中。

点击此处查看 update_window_start() 代码详解。

⑶ 如果任务刚初始化结束

如果任务刚初始化结束:if(!p->ravg.mark_start),还没有标记过任务的开始时间,就先通过函数 update_task_cpu_cycles() 更新一下该任务的 cycles 值(p->cpu_cycles),然后进入 done

⑷ 更新任务及 CPU 的 cycles

update_task_cpu_cycles() 相似,但比其多更新了 CPU 的 cycles 值(rq->cc.cycles)。

该函数更新的值会在 scale_exec_time() 中被用到。

⑸ 更新任务及 CPU 的 demand 及 pred_demand

在任务满足条件后,在不同情况下根据任务的开始时间、窗口的开始时间以及当前时间来计算任务在当前及之前M个窗口中的运行时间。在窗口结束时将运行时间进行归一化,并统计进任务的历史窗口中(sum_history[RAVG_HIST_SIZE])。

WALT 算法根据历史窗口中的值计算任务的 demand,根据桶算法计算任务的 pred_demand,并将 demand 与 pred_demand 统计进任务所在 CPU 的 rq(runqueue)中。

注意:以上说的 demand 与 pred_demand 都是预测值。

点击此处查看 update_task_demand() 代码详解。

⑹ 更新 CPU 的 busy time

在任务满足条件后,在不同情况下根据任务的开始时间、窗口的开始时间以及当前时间来计算任务在当前及上一个窗口中的运行时间,将不同窗口内的运行时间进行归一化,并根据任务的状态统计进任务的 curr_windowprev_window 中,以及任务所在 rq 的 curr_runnable_sumprev_runnable_sum 中。

在窗口翻滚的时候更新任务的 window 值 以及 rq 的 runnable_sum 的值。

注意:以上说的 window 以及 runnable_sum 都是真实值。

点击此处查看 update_cpu_busy_time() 代码详解。

⑺ 更新任务的 pred_demand

如果符合条件的任务在当前窗口中预测出来的 pred_demand 值小于 curr_window,则再次使用桶算法计算 pred_demand。

点击此处查看 update_task_pred_demand() 代码详解。

⑻ 如果任务正在退出

#define EXITING_TASK_MARKER	0xdeaddead

static inline int exiting_task(struct task_struct *p)
{
	return (p->ravg.sum_history[0] == EXITING_TASK_MARKER);
}

当任务最近一个窗口的值为 0xdeaddead 时,意味着任务正在退出,进入 done

done 结束部分:

  1. 更新一下任务的开始时间:p->ravg.mark_start = wallclock
  2. 执行 run_walt_irq_work(),判断是否需要计算频率。具体可以查看 【WALT】频率计算

函数调用时机

<kernel/sched/core.c>

  1. try_to_wake_up()
  2. try_to_wake_up_local()
  3. scheduler_tick()
  4. __schedule()
  5. sched_exit()

<kernel/sched/walt.c>

  1. sched_account_irqtime()
  2. fixup_busy_time()
  3. cpufreq_notifier_trans()
  4. transfer_busy_time()
  5. walt_irq_work()
<think>好的,我现在需要帮助用户寻找与WALT相关的线程组信息,特别是在IT上下文中。首先,我需要回忆一下WALT(Window-Assisted Load Tracking)的相关知识。WALT主要用于Linux调度器中,特别是在任务负载跟踪和CPU资源分配方面。用户提到了引用[1]和引用[2],这些可能涉及到WALT在窗口翻滚时如何计算任务需求(demand)和预测需求(pred_demand),以及任务效用平均值(util_avg)的处理。 接下来,我需要确定线程组(thread group)在Linux中的定义。线程组通常指的是属于同一进程的多个线程,它们共享相同的进程ID(PID),但有不同的线程ID(TID)。在调度器中,线程组的调度策略和资源分配可能会有特殊处理,特别是当涉及到负载均衡和任务迁移时。 用户的问题是关于WALT相关的线程组信息,所以我需要查找WALT如何与线程组交互。例如,WALT可能在计算任务负载时,是否考虑线程组整体的负载,或者是否有特定的数据结构来管理线程组的调度信息。引用[3]提到了每个CPU有一个就绪队列(struct rq),这可能与线程组的调度有关,因为不同的线程可能分布在不同的CPU上,而调度器需要平衡它们的负载。 根据引用[1],WALT在窗口翻滚时计算demand和pred_demand,这可能涉及到将同一线程组中的线程的负载进行汇总或预测。例如,如果一个线程组包含多个线程,WALT可能需要聚合这些线程的负载需求,以便更准确地分配CPU资源。此外,引用[2]提到task的util_avg在最后一次出队时的值,这可能影响线程组的整体效用计算。 现在,我需要确认在Linux内核代码中,是否有与WALT相关的线程组处理部分。例如,在调度器代码中,当处理线程组时,是否调用了WALT的相关函数来更新负载或预测需求。另外,可能需要查看与cgroup(控制组)相关的部分,因为线程组可能与cgroup相关联,影响资源分配。 可能的代码路径包括kernel/sched目录下的文件,如fair.c、walt.c等。例如,在更新任务负载时,WALT可能会遍历线程组中的所有线程,累加它们的负载需求。或者在任务迁移时,调整线程组的负载统计。 如果用户需要具体的信息,可能需要指导他们查看内核代码中的相关结构体,如struct task_struct中的thread_group字段,或者与调度组(sched_group)相关的部分。此外,WALT可能为线程组维护特定的指标,如组级别的demand或util_avg,这些信息可能存储在特定的结构体中。 总结来说,用户可能需要了解WALT在处理线程组时的负载跟踪机制,包括如何聚合线程的负载、预测需求,以及这些信息如何影响调度决策。建议用户查阅内核源码中与WALT相关的线程组处理部分,特别是涉及任务组负载计算和调度的代码。</think>在 Linux 调度器框架中,WALT (Window-Assisted Load Tracking) 主要通过 `struct walt_task_group` 数据结构管理线程组级别的负载跟踪信息。该结构定义在 `kernel/sched/walt.h` 中,关键字段包括: $$tg_load = \sum_{i=1}^{n} task\_demand_i$$ 其中 $n$ 表示线程组内的任务数量,$task\_demand_i$ 是组内第 $i$ 个任务在窗口期的需求值[^1]。 ### WALT 线程组关联要素 1. **cgroup 层级集成** - 通过 `/sys/fs/cgroup/cpu` 目录下的控制组参数实现层级化负载跟踪 - `cpu.walt_util` 文件节点暴露线程组聚合利用率 2. **调度决策影响** ```c // kernel/sched/fair.c static void update_cpu_busy_time(struct task_struct *p, struct rq *rq) { struct walt_task_group *wtg = p->wtg; if (wtg) { wtg->demand += p->walt_stats.demand; update_tg_load_avg(wtg); } } ``` 该代码段展示了任务负载如何向上聚合到线程组[^2] 3. **跨 CPU 负载平衡** - 就绪队列 `struct rq` 的 `avg_walt_tg_load` 字段记录线程组负载 - 在 `find_busiest_queue()` 中用于比较不同 CPU 的负载压力[^3]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值