我干了20几年码农，发现好多童鞋学习Linux内核的思路是错误的，他们不是在探索Linux内核，只是在做Linux内核代码的复读机。
前面我们已经强调，代码是现实的映射。我们研究Linux内核的代码，第一步永远是从现实到代码（而不是直接从代码到现实），随后需要进行现实到代码、代码到现实的反复比照，但是第一步永远是理解现实的出发点。
设想我们现在有n个CPU，有m个task_struct要跑。任何的操作系统的调度器，它必然都会面对这样的一些疑问和必须解决如下的一些问题：
1.究竟有多少个task_struct要跑，我们需要一个方式来记录，把它们组织到一个数据结构里面去；
2.这么多task_struct，它们各自的特性是不一样的，比如有的是周期性跑的，有的是很紧急的（不及时处理就会有更严重的后果，比如同样都是上厕所，一个拉肚子的人优先级是非常高的，不然可能拉裤子里，其他情况往往还能忍很久），有的则强调公平配额，有的无所谓，你们都不跑的时候我再跑就行。
3.在问题1中，假设我们已经用数据结构维护好了task_struct，那么问题2，就是要解决不同task_struct的不同调度策略，在这么多task_struct究竟先跑谁的问题。
4.既然task_struct有轻重缓急，那么一个task_struct在某CPU跑的时候，可不可以被其他更紧急的task_struct抢占，如果可以，谁可以抢占谁，什么时候允许抢占？
5.如何把m个task_struct放到n个CPU上面去，哪个task_struct适合哪个CPU?会不会出现n个CPU累的累死，闲的闲死？例外，这n个CPU的拓扑结构如何，哪些CPU和哪些CPU比较靠近，而哪些又比较远？如何根据task_struct之间的关联，把它们合理地依据拓扑结构放到合适的CPU上面去？
6.所有task_struct的排布一定是扁平的吗？比如张三登录了一台服务器开启100线程编译内核，李四登录开启了20个线程编译内核，会不会出现张三通过线程多而占了所有CPU能力的80%，而李四只占20%的情况？如果出现，是否需要将task_struct进行层次化管理而不是扁平管理，比如张三的是一群，李四的是一群，先追求张三群和李四群的公平，再追求张三或李四群内部task_struct之间的公平？
7.有对一切场景都同时友好的宇宙通用的调度器吗？如果没有，调度器如何适应不同业务场景的变化？
我们发出上述的“天问”，其实是在拷问我们自己，如果你是Linux内核调度器的作者之一，你要怎么做。我们从来不被动接受别人是怎么做的事实，因为我们不是Linux内核的复读机，我们应该是开拓者。
