LWN: OSPM会议上讨论SCHED_DEADLINE和SCHED_RT的路线图

OSPM会议上讨论了SCHED_DEADLINE与SCHED_RT在容量受限及非对称容量系统中的应用前景。SCHED_DEADLINE需改进以应对动态变压变频等现代特性,同时需解决在性能限制下的硬实时保证问题。而SCHED_RT则需优化其CPU分配策略以适应现代移动平台。
640点击上方蓝色字关注我们~



The future of SCHED_DEADLINE and SCHED_RT for capacity-constrained and asymmetric-capacity systems

July 10, 2019



OSPM

译者注:OSPM是刚刚结束的第三届Operating-System-Directed Power-Management summit会议。近期LWN发布了一部分会议议题的讨论。本文正是其中一篇。


Kernel已经有了一个调度策略名为SCHED_DEADLINE,专门用于每个任务都需要在给定的时间期限(deadline)之内来完成的这种实时调度场景。不过,可惜的是SCHED_DEADLINE目前对CPU能力的抽象还太简化,完全没有考虑动态变压变频(DVFS),并发多线程处理(SMT),非对称的CPU能力(例如ARM big.LITTLE),以及各种性能限制策略(例如温度过高时需要限制CPU性能)。

特别是如果要在一个有性能限制策略的系统上执行deadline tasks(需要在给定时间期限内完成的Task)的话,就非常需要理解清楚SCHED_DEADLINE具体能提供什么样的保证。在此次会议中有关于各种方案(weak, hard, or mixed guarantees)的优劣对比。会议上有很多种不同观点,大家最终也没有达成一致,会需要在今年不久之后将会召开的Linux Plumbers Conference上继续探讨。

对移动设备来说,今后因为温度控制等原因进行性能限制会更加平常,因此在这种情况下如何保证性能,会是越来越重要的话题。要提供硬实时保证基本上是不可能的,因为芯片的行为受环境影响很大(例如天气太热)。对目前方案的主要反对观点在于所保证的带宽有点过于保守了。因此SCHED_DEADLINE针对那些需要高带宽的使用场景就可能没法预留足够带宽,哪怕这个task可以允许预留带宽偶尔被占用也不行。


后来这个话题又转移到讨论“tunable granted capacity”的概念(这个概念其实永远都是受限于合理的工作条件前提下的)以及一个最大的“best-effort capacity”。这样模型就能让SCHED_DEADLINE把各个task分为两类不同的服务对象,这样就能知道哪些task会更无法忍受CPU资源减少之后导致的错过deadline。不过这种方案会让kernel里的admission-control policy更加复杂。还有一种可能的策略就是让kernel内部admission control尽量简单,但是在user space增加一些特权用户可以使用的、更加高级的admission-control policy。


此外在现代的移动平台上对SCHED_DEADLINE还有多个方面的改善。Luca Abeni提供的"Capacity awareness for SCHED_DEADLINE" RFC patch set能够对非对称CPU能力的场景下提供基本功能。还有一些需要更长周期完成的工作,例如探索是否可能让在做admission control判断的时候能根据硬件或者固件所能提供的性能指标来决策,还有引入energy-aware task在deadline scheduler里的支持。


关于realtime scheduling class (SCHED_RT),在移动设备上使用的话也有一些问题。Linux mainline代码里会缺省把RT任务放在拥有最多空闲计算能力的CPU上去执行,这个方案有些太极端,有点浪费。SCHED_RT也假设CPU的计算能力全部都是对称的,此外它还不会参考当前running或者runnable的CFS进程情况来做决策。


SCHED_RT也就跟SCHED_DEADLINE一样,需要做一些改进才能在现代移动平台上更加实用。已经合入了一个utilization clamping patch set(会包含在Linux 5.3),它可以采用per-task, per-task-group或者系统全局的performance上限限制来对各个CPU的频率进行更细粒度的决策。此外还有一些其他改进,例如让SCHED_RT能在非对称的CPU能力的系统上,根据每个CPU的计算能力来预测可以获得的性能提升,又或者让SCHED_RT也和CFS task能互相考虑,从而实现更好的调度策略。


全文完

LWN文章遵循CC BY-SA 4.0许可协议。

极度欢迎将文章分享到朋友圈 
热烈欢迎转载以及基于现有协议上的修改再创作~


长按下面二维码关注:Linux News搬运工,希望每周的深度文章以及开源社区的各种新近言论,能够让大家满意~


640?wx_fmt=jpeg

<think> 嗯,用户这次的问题非常具体,是关于kernel_device_modules-6.6构建过程中mgk_64_k66_customer_modules_install.user失败的解决方案。从问题描述看,用户应该是嵌入式Linux开发工程师,正在定制内核模块,遇到构建中断的问题。 上次对话中用户提到了“kernel_device_modules-6.6”这个关键词,说明是在处理内核设备模块的编译问题。这次报错文件扩展名.user比较特殊,像是某种自定义构建脚本。用户能准确提供文件名,说明已经有一定技术基础,可能排查过基础路径问题。 需要特别注意几个关键点:一是“kernel_device_modules-6.6”这个项目名称看起来像商业嵌入式方案,可能是客户定制内核;二是“mgk_64_k66”这个前缀,mgk可能是模块组缩写,64指64位架构,k66疑似指NXP的Kinetis K66微控制器;三是构建脚本后缀.user比较罕见,可能是企业内部自定义的构建系统。 构建失败通常有几类原因:环境配置问题(如交叉编译器缺失)、脚本逻辑错误(路径处理不当)、依赖缺失(头文件或库文件)、权限问题等。考虑到.user脚本的特殊性,应该优先检查:1)执行权限;2)脚本内部路径是否正确指向内核源码目录;3)交叉编译工具链是否配置。 用户没有提供具体错误日志是最棘手的。需要引导用户提供更多信息,比如构建时的终端输出、脚本开头部分的路径配置等。另外要注意这个模块可能是依赖特定内核配置选项的,需要确认.config文件中相关驱动是否启用。 最后要提醒用户注意风险——这类定制内核模块的构建失败往往涉及多方因素,企业内部的构建系统可能还有非公开依赖。建议用户先联系原厂支持渠道,同时提供尽可能详细的错误信息方便进一步排查。 </think> 针对 `kernel_device_modules-6.6` 中 `mgk_64_k66_customer_modules_install.user` 构建失败的解决方案,请按以下步骤排查: --- ### **排查步骤** #### 1. **检查构建环境** - **内核源码完整性** 确认 `kernel_device_modules-6.6` 源码完整且与当前运行内核版本一致: ```bash uname -r # 查看当前内核版本 ls /lib/modules/$(uname -r)/build # 验证内核头文件存在 ``` 若路径缺失,需安装对应内核头文件包[^1]。 - **交叉编译工具链** 若为嵌入式设备(如 `k66` 可能指 NXP Kinetis K66),检查交叉编译器是否配置: ```bash echo $CC # 查看环境变量 arm-none-eabi-gcc --version # 示例(具体工具链名称需确认) ``` #### 2. **分析构建日志** - 查找错误关键字(如 `Error`/`Failed`): ```bash grep -i "error\|failed" build.log # 替换为实际日志文件名 ``` **常见问题方向**: - **依赖缺失**:如 `undefined reference` 提示缺少库或头文件 - **语法错误**:内核 API 变更导致函数签名不兼容 - **权限问题**:`Permission denied` 提示需 `sudo` 或修复路径权限 #### 3. **验证脚本权限与路径** - 添加可执行权限: ```bash chmod +x mgk_64_k66_customer_modules_install.user ``` - 检查脚本内路径是否为**绝对路径**(避免相对路径嵌套错误): ```bash head -n 20 mgk_64_k66_customer_modules_install.user # 查看脚本头部配置 ``` #### 4. **依赖项检查** - 安装基础编译依赖: ```bash sudo apt-get install build-essential libssl-dev flex bison libelf-dev ``` - 确认模块特殊依赖(如厂商 SDK、闭源驱动)是否部署。 #### 5. **兼容性调整** - **内核符号导出问题**: 若日志含 `Unknown symbol`,需在模块代码中添加导出声明: ```c EXPORT_SYMBOL(your_function); // 内核源码中声明 ``` - **版本适配**: 若内核 ≥5.7,需替换弃用的 `get_user_pages()` 为 `get_user_pages_remote()`[^2]。 #### 6. **增量构建测试** - 分步编译定位故障点: ```bash make -C /lib/modules/$(uname -r)/build M=$(pwd) modules # 仅编译模块 sudo insmod your_module.ko # 手动加载测试 ``` --- ### **典型错误场景与修复** | **错误类型** | **解决方案** | |------------------------|------------------------------------------| | **`Makefile: No such file`** | 确认脚本中 `KERNEL_SRC` 路径正确指向内核源码目录 | | **`Invalid module format`** | 强制编译目标版本:`make KERNELRELEASE=$(uname -r)` | | **`undefined reference`** | 检查模块依赖链,添加 `obj-m += dependent_module.o` | | **`Function not implemented`** | 替换新版内核 API(如 `vmalloc_user()` 替代旧接口) | --- ### **补充建议** 1. **联系厂商支持**: `mgk_64_k66` 可能是定制模块,需获取厂商提供的补丁或更新脚本。 2. **版本回退测试**: 尝试旧内核版本(如 5.4 LTS)验证是否兼容性问题。 3. **调试符号分析**: 启用 `CONFIG_DEBUG_INFO=y` 后使用 `dmesg` 查看详细崩溃堆栈。 > 请优先提供 **完整构建日志** 以精准定位问题。若上述步骤未解决,建议提交日志到社区论坛(如 [Stack Overflow](https://stackoverflow.com))或内核邮件列表[^3]。 --- [^1]: 内核头文件安装参考:[Ubuntu Kernel Headers](https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel) [^2]: 内核 API 变更说明:[Linux 5.7 API Changes](https://lwn.net/Articles/817101/) [^3]: 内核社区支持:[LKML (Linux Kernel Mailing List)](https://lkml.org/)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值