sched_ext是什么? 可以看: https://bbs.deepin.org.cn/post/301957
在最开始,我给deepin的Linux 6.6内核做了个backport支持: https://bbs.deepin.org.cn/post/301958
但随后因为不可持续维护性(可持续维护要求直接从上游cherry-pick代码提交),因此我做的第一版backport作用只是进行了验证,随后我在国庆按照可维护性要求完成了backport到6.12基线, 但紧接着我发现backport到6.12基线开不了scx_lavd, 于是我又往前backport了几步基本backport全让scx_lavd能开起来
但随后我在deepin内测SIG里交流,开发告诉我龙蜥社区其实做了sched_ext实现,那我寻思既然国内有社区做了实现,就让ABI遵守先做出来的,跟龙蜥的ABI保持一致,在今天完成了这个任务,最终成品链接也是在那个PR链接上(我直接force-push覆盖了)
这么做有缺点, 就是scx 1.1.3里很多调度开不了,因为它们需要新的内核节点(也就是新的sched_ext实现),针对这个我主要针对Valve主导的lavd调度做了backport确保能正常开启(用6.18内核的用户不必担心,本来就能开),我做的scx的backport版链接: https://github.com/Better-Deepin-Repo/scx
现在我基本做到了给deepin的6.6信创内核backport基本可用的sched_ext实现,且sched_ext的ABI跟龙蜥社区的Linux 6.6内核保持一致,理论上针对龙蜥内核特调的sched_ext调度能直接跑在我实现的deepin 6.6内核的sched_ext上
Featured Collection
Popular Ranking
Popular Events
sched_ext是什么? 可以看: https://bbs.deepin.org.cn/post/301957
在最开始,我给deepin的Linux 6.6内核做了个backport支持: https://bbs.deepin.org.cn/post/301958
但随后因为不可持续维护性(可持续维护要求直接从上游cherry-pick代码提交),因此我做的第一版backport作用只是进行了验证,随后我在国庆按照可维护性要求完成了backport到6.12基线, 但紧接着我发现backport到6.12基线开不了scx_lavd, 于是我又往前backport了几步基本backport全让scx_lavd能开起来
但随后我在deepin内测SIG里交流,开发告诉我龙蜥社区其实做了sched_ext实现,那我寻思既然国内有社区做了实现,就让ABI遵守先做出来的,跟龙蜥的ABI保持一致,在今天完成了这个任务,最终成品链接也是在那个PR链接上(我直接force-push覆盖了)
这么做有缺点, 就是scx 1.1.3里很多调度开不了,因为它们需要新的内核节点(也就是新的sched_ext实现),针对这个我主要针对Valve主导的lavd调度做了backport确保能正常开启(用6.18内核的用户不必担心,本来就能开),我做的scx的backport版链接: https://github.com/Better-Deepin-Repo/scx
现在我基本做到了给deepin的6.6信创内核backport基本可用的sched_ext实现,且sched_ext的ABI跟龙蜥社区的Linux 6.6内核保持一致,理论上针对龙蜥内核特调的sched_ext调度能直接跑在我实现的deepin 6.6内核的sched_ext上