wenxl

"一个entity对系统负载的贡献可以根据该实体处于runnable状态（正在CPU上运行或者等待cpu调度运行）的时间进行计算" --------------------------------------------------------------------------------------------- 这里是否存在问题，正在cpu上运行不是runnable状态吧？

《CFS调度器（4）-PELT(per entity load tracking)》发表时间：2022-07-20 10:15

donbear

感谢分享，很精彩啊。有一个疑问希望能得到博主的解答。在通过 *sum 计算 *avg 的时候，为什么是除以几何级数的最大值？按照linux中源码注释以及各处看到的公式，这里貌似除1024就可以了？:( static __always_inline void ___update_load_avg(struct sched_avg *sa, unsigned long load) { u32 divider = get_pelt_divider(sa); /* * Step 2: update *_avg. */ sa->load_avg = div_u64(load * sa->load_sum, divider); sa->runnable_avg = div_u64(sa->runnable_sum, divider); WRITE_ONCE(sa->util_avg, sa->util_sum / divider); } 看了博文这里的解释，还是一头雾水：在计算sum值的时候，runnable和running sum都是进行了scale操作（左移10bit），因此在计算avg的时候，直接除以序列最大值就OK了。通过get_pelt_divider可以获得PELT几何序列的最大值。博主能详细解答一下么？非常感谢。

《PELT算法浅析》发表时间：2022-07-17 22:01

王传琪

@王传琪：感觉前面描述的有点问题，改一下。我在看pinctrl_register注册的时候有个疑问，就是pinctrl driver也是一个platform driver，走的标准的driver注册流程。会进入到really_probe这个函数，然后也会调用pinctrl_bind_pins，去绑定和设置默认io，但这个时候pinctrl driver是还没有执行probe的，也就是pinctrl_register是没有执行的，那就在pinctrldev_list这列表里面是找不到pinctrl_dev，那pinctrl_bind_pins在get_pinctrl_dev_from_of_node是找不到pinctrl_dev，这样好像会导致pinctrl驱动会加载失败呀。

《Linux内核中的GPIO系统之（3）：pin controller driver代码分析》发表时间：2022-07-15 18:34

王传琪

各位大佬好！我在看pinctrl_register注册的时候有个疑问，就是pinctrl子系统也是一个platform driver，这样他也是走的标准的driver注册流程。会进入到really_probe这个函数，然后也会调用pinctrl_bind_pins，去绑定和设置默认io，但这个时候pinctrl是还没有执行probe的，也就是pinctrl_register还没有注册，那就在pinctrldev_list这列表里面是找不到pinctrl_dev，这样好像会导致pinctrl驱动会加载失败呀。看了好久，还是没有找到是怎么对这个进行处理的，望各位大佬指点一二

《Linux内核中的GPIO系统之（3）：pin controller driver代码分析》发表时间：2022-07-15 18:29

qp123

谢谢你这么无私的人

《u-boot启动流程分析(2)_板级(board)部分》发表时间：2022-07-12 19:43

点灯大师

怒赞

《关于蜗窝》发表时间：2022-07-06 18:04

lamb

@jackzhous：kernel待机、睡眠过程看这篇入门，系统睡眠的入口在这里 http://www.wowotech.net/pm_subsystem/autosleep.html

《Linux电源管理(15)_PM OPP Interface》发表时间：2022-07-04 17:59

雁落

那张uboot架构图是你自己理解画出来的吗，把我惊住了