蜗窝科技

@hhtrace：是不是任意指定一个cpu运行？

最近在学习NUMA，有个问题不明白： 比如一个驱动，使用的是per cpu workqueu，但是使用的内存却在node0上，那么workqueue最后会跑到node1上运行吗？ 谢谢

@秋暮离：我觉得，uart永远都比cpu慢：因此从uart的角度考虑（代价是浪费CPU，值得吗？），fifo越小越好（cpu就可以及时的处理数据）；但从cpu的角度考虑（尽量节省cpu），fifo越大越好，这样cpu就可以去做其它事情，偶尔过来处理一下uart数据即可（当然，代价也是一目了然的）。

wowo好， 如果FIFO阈值可以修改，出于传输效率考虑，以下想法是否正确？ 1、假设CPUa快于CPUb,则a的TX FIFO阈值要设的小于b,a的RX FIFO阈值要设的大于b（uart发送速率一样的前提下）？ 2、是不是因为实际CPU速度相对外设来说都很快，所以TX FIFO阈值都要尽量设的低些，RX FIFO阈值尽量设备高些？

@江南书生：clock就是钟表啊，从上面可以读取当前时间的一种工具。timer总是基于某个clock而言的，当clock推进到某个时间点的时候会触发调用timer的callback函数。

@wpch：多谢wpch网友的回复，技术问题越多人讨论越清晰。 由于工作和家庭的原因，其实我很难做到快速回复的，见谅！felix同学，我非常喜欢你的问题，很有意思，我是这么想的：如果你要自己设计一个OS，那么你是考虑如何设计时间子系统呢？其实是可以完全抛弃tick的概念，让整个系统的计时都是以ns为单位的，timer也都是基于ns的。内核的各个模块以及userspace的posix timer请求（最终也是内核的hrtimer）都最终被统一挂入一个数据结构中（也许是红黑树），在这样的思路指导下，调度模块自己设定自己的hrtimer，来处理各个进程的时间统计和调度，kernel profiling模块设定自己的hrtimer，来完成profile_tick函数中的各种任务。总之，就是各个模块设定自己的hrtimer，没有什么tick的东西，原来在tick中处理的所有的事情可以推回给各个模块，让他们自己不断的设定周期性timer来解决，这样的系统好不好呢？当然好，简洁而美丽。 虽然软件结构好了，但是，这样实现导致的一个问题就是hw timer的中断太多了，一方面，在系统运行状态，很多模块可能都有每10ms需要处理日常性事务的需求（例如timekeeping模块需要更新系统时间、调度模块需要统计进程时间等），如果各自为政，那么各个模块的这种10ms的hrtimer都会各自触发中断（因为初始相位是不一样的），如果有tick的话，那么一次tick，可以统一为这些模块处理这些housekeeping task。另外一方面，实际上timer的需求还是有两种情况：一种是需要精确的时间（例如多媒体应用），另外一种就是简单的超时处理1S之后检查某种设备的状态，但是1.01秒之后检查也没有什么关系。如果对第二种场景也使用hrtimer来应对，那么也会造成过多timer中断，使用tick来推动第二种timer需求会更好一些。 Timer中太多有什么坏处呢？一方面，timer interrupt handler消耗了额外的cpu处理时间，另外，更重要的是会造成processor cache thrashing的问题。这些都会造成性能和功耗方面的问题。

@felix 插两句，CPU是因为无事可做才进入idle状态的，既然有hrtimer到期了自然就要唤醒处理，感觉你有点本末倒置了；系统的调度、时间的更新这些都依赖于周期性tick，你看一下tick中的处理应该就理解了

老板，你好！ 请问clock和timer有什么不同么？看了这么多文章一直在思考，都是对脉冲计数的啊？请问能不能用个例子说明一下不同呀？

@linuxer：十分感谢你的回复，昨天到现在一直等待你的回复，终于等到了！！ 低精度timer依赖周期性tick，而hrtimer不依赖周期性tick，这个对我帮助很大！！ 另外，对这段话：<<假设time wheel中寻找最早到期的低精度timer是10秒，那么模拟tick的那个sched_timer就会被停止运作10秒，当然，在10秒内可能有非常多的hr timer在红黑树中，他们怎么办？没有什么怎么办，该触发的还是触发，hrtimer仍然按照其既定的规律运作，hw timer中断仍然按照hrtimer模块设定的规律触发。停掉tick并不是意味着停到hw timer的interrupt。>> 我还存在疑问，tickless的初衷是为了节能的考虑，所以停止没有必要的周期性tick。如果10s内有很多hrtimer不断的打断cpu睡眠，这个就和系统节能的本意不符合了。tickless就只是考虑周期性tick，对于杂乱的hrtimer的中断不予考虑？另外，想请教您一点，周期性tick存在的必要性是什么？

@felix：多谢你的解释，我也按照你的思路走读了一遍代码，我是这样考虑的：hrtimer本身是不依赖于tick的，因此它的逻辑很简单，hrtimer到期后执行callback，然后就是从红黑树中摘下最近的那个hrtimer，设定下一次触发的时间点，如此周而复始。因此，hw timer的中断触发时间是和红黑树中的hrtimer有关，如果红黑树是空的，那么hw timer就静默了。 当然，实际情况没有那么简单，因为目前内核运行了高精度和低精度timer两套系统，而低精度timer是基于tick的（具体为何如此，这说来话长，网上资料也很多，这里就不赘述了）。在这样的情况下，内核用一个hrtiemr实现了以一个HZ为间隔的周期性tick，而这个tick又推动了低精度timer的运作。 OK，说道tickless，其实就是停掉没有必要的tick，实际上只有低精度timer是依赖于tick的，因此也就不难理解为何在tick_nohz_stop_sched_tick函数中，只从time wheel中寻找最早到期的低精度timer来决定是否stop模拟tick的那个hrtimer。 假设time wheel中寻找最早到期的低精度timer是10秒，那么模拟tick的那个sched_timer就会被停止运作10秒，当然，在10秒内可能有非常多的hr timer在红黑树中，他们怎么办？没有什么怎么办，该触发的还是触发，hrtimer仍然按照其既定的规律运作，hw timer中断仍然按照hrtimer模块设定的规律触发。停掉tick并不是意味着停到hw timer的interrupt。