Chinaunix首页 | 论坛 | 博客
  • 博客访问: 244206
  • 博文数量: 32
  • 博客积分: 557
  • 博客等级: 中士
  • 技术积分: 431
  • 用 户 组: 普通用户
  • 注册时间: 2011-04-20 23:05
文章分类

全部博文(32)

文章存档

2015年(4)

2014年(2)

2012年(4)

2011年(22)

分类: LINUX

2011-07-21 18:25:49

请看附件,里面使用了公式编辑器,word打开需开启宏
 按照RCU的分析经验,上来就先看了相关的数据结构,然后找到sched_init函数,准备画架构图,却也分析的云里雾里。这也是正常的,马克思教导我们,发展要经历否定之否定,任何事情都是螺旋上升的。所以不可能一次将这一块完全搞清楚,必须在有个大概的轮廓之后,再结合其他部分对这些数据结构的应用,才能更清楚的理解。

牵涉到的数据结构主要有sched_group, sched_domain, sched_class, sched_statistics, sched_entity, sched_rt_entity;
task_struct, task_group, runqueue, cfs_rq.

在这里也能体现出管理流与执行流的区别,在这里执行流就是进程调度,即从rq中选出task_struct来执行,以及对进程状态变化的处理;管理流就是CPU负载平衡。

已经看了两天,执行流中各数据结构的关系(rq, cfs_rq, se, ts)相对清晰;平衡流中数据结构(rq, cpu, sd, sg, tg, cgroup)很是复杂,并且牵涉其他模块如cpumask, cgroup,topology等,其他概念如SMT/MC/SMP/NUMA。并且这只是初始化部分,随着CPU hotplug,和cgroup task_group的创建和销毁,还会增加和删除sched_doamin。

好,有难度才好,有问题就一个一个的列出来,摆正顺序,一个一个克服。
列出来就会发现其实也就只有那几个问题。

本文会研究两个方面:
① CFS/RT进程调度算法关联的数据结构含义,忽略statistics;
② 负载均衡,前期重点在于理清sched_domain、sched_group的关系,后期研究过载与平衡的过程;
③ 为达成以上两点,需要具备的知识,过程中解决

本人基础:
① 去年大致看过schedule函数,sched fair的enqueue,dequeue过程;
② ULK3 看过两遍(忘了很大一部分)

PS: damn chinaunix,从blog换成了blog168,看来要做两手准备了,这些东西不好丢,丢不起;
本文内容,同时参见

总结全文
画图,去除“.png”后缀,使用visio查看
介绍multi-core的load-balance时performace and power saving之间的权衡
介绍根据ACPI SLIT构建multi-level sched_domain结构
阅读(11868) | 评论(41) | 转发(3) |
给主人留下些什么吧!~~

wangjianchangdx2011-08-04 23:53:03

上面搜索到的是mpparse.c 中的smp_read_mpc函数,该函数遍历mptable中的每一行,其中与CPU数目相关的在MP_PROCESSOR switch case,接下来MP_processor_info->generic_processor_info,在后一个函数中,有这样一段注释:
/*
* x86_bios_cpu_apicid is required to have processors listed
* in same order as logical cpu numbers. Hence the first
* entry is BSP, and so on.
*/
可以推测这个表里面是区分了phys cpu和logical cpu的。
OK,这个暂时告一段落吧,其实这里还缺少从smp_read_mpc向上的回溯(也可以回溯到setup_arch),还是记录一下回溯的方法吧:
① jump to caller: check_physpt

wangjianchangdx2011-08-04 23:10:56

呵呵,之前跟start_kernel的时候,跟到setup_arch的时候,只注意到最开始的early_cpu_init(),却没有注意到之后的prefill_possible_map();

这次从系统上电的流程大致的跟,想着如果要对cpu_possible_bits赋值的话,一定要到jump to protected mode之后了,跟到arch/x86/kernel/head_32.S时,搜索了一下possible_cpu,搜到了smpboot.c中的
static int __init _setup_possible_cpus(char *str)
{
        get_option(&str, &setup_possible_cpus);
        return 0;
}
early_param("possible_cpus", _setu

wangjianchangdx2011-08-04 22:01:54

setup_per_cpu_areas()在start_kernel函数很早的地方,这就说明cpu_possible_map在之前就已经被set好了,要么在start_kernel中,要么在之前的汇编代码中;

cpu_possible_map虽然有可能包括MC/SMT对应的logical CPU,但是它的设置却很可能与CONFIG_MC/SMT无关,而与SMP有点关系,也有可能根据NR_CPUS直接全部设置为possible,再跟一跟看看是如何discovery的

wangjianchangdx2011-08-04 21:50:11

Documentation/cpu-hotplug.txt:
cpu_possible_map: Bitmap of possible CPUs that can ever be available in the
system. This is used to allocate some boot time memory for per_cpu variables
that aren't designed to grow/shrink as CPUs are made available or removed.
_Once set during boot time discovery phase_, the map is static, i.e no bits
are added or removed anytime.  Trimming it accurately for your system needs
upfront can save some boot time memor

wangjianchangdx2011-08-04 16:04:46

arch/x86/kernel/smpboot.c:
cpu_possible_mask should be static, it cannot change as cpu's
* are onlined, or offlined. The reason is per-cpu data-structures
* are allocated by some modules at init time, and dont expect to
* do this dynamically on cpu arrival/departure.