Udev 内核机制(kobject_uevent) 性能优化(转载)
2012-12-06 20:52
246 查看
Udev 内核机制(kobject_uevent) 性能优化
前言
这两天遇到一些 udev 的问题, 顺便阅读了一下文档(见参考文档), 基本了解了 udev 的机制。嵌入式系统性能很重要,于是对内核这一块进行了性能方面的研究。
内核大概20多处会调用了 kobject_uevent 函数发送 KOBJ_ADD / KOBJ_REMOVE 等事件。其中我们最关心的就是在device_add/device_del 中向用户空间发送设备的添加、删除信息。
kobject_uevent 直接调用 kobject_uevent_env 函数完成功能,我们先分析一下该函数的流程。
kobject_uevent_env调用流程 (内核版本 2.6.21)
kobject_uevent_env首先搜索 kobject 所属的 kset, 获得kset->uevent_ops,类型为kset_uevent_ops (系统一共有block_uevent_ops memory_uevent_ops device_uevent_ops class_uevent_ops module_uevent_ops )这几大类 kset_uevent_ops,我们这里主要看device_uevent_ops。
如果 uevent_ops 有 filter 成员函数, 则调用该函数,如果filter函数返回非0,则失败,结束流程。device_uevent_ops 的 filter函数为 dev_uevent_filter, 它的过滤条件为该设备的总线(bus) 或者类 (class) 非空。
为 envp分配一个大小为 32 的数组, 用于存储环境变量指针,为 buffer 分配一个大小为 2048 的数组,用于存储环境变量内容。
初始化环境变量, 包括 HOME PATH ACTION DEVPATH SUBSYSTEM 等
如果 uevent_ops 有 uevent 函数,则调用该函数,如果uevent函数返回非0,则失败,结束流程。device_uevent_ops 的 uevent 函数为dev_uevent,它的流程为:
添加主次设备号到环境变量
添加 driver 的名称到环境变量
如果设备所属总线 (dev->bus)有 uevent函数, 则调用它。如失败,结束流程
如果设备所属类 (dev->class)有 uevent函数,则调用它。如失败,结束流程。(象函数_request_firmware ()中,有两次调用kobject_uevent函数,其中第一次在class 的 uevent函数firmware_uevent中,测试 FW_STATUS_READY位失败而返回)。
如果设备所属类型 (dev->type)有 uevent函数, 则调用它。如失败,结束流程. (搜索了一下, 这个field 在整个内核里基本没有使用)
注意每个 uevent 函数都有机会添加环境变量以及出错返回,结束uevent传递。
递增 uevent 序列号uevent_seqnum(可以通过 cat /sys/kernel/uevent_seqnum 查看)。
如果定义了 CONFIG_NET 通过 netlink 将事件以及环境变量发送出去。
如果uevent_helper 非空, 则调用该函数。uevent_helper 的缺省值为: "/sbin/hotplug" 应该在用户层调用:echo "" > /sys/kernel/uevent_helper 来取消该此调用。
性能数据统计
我们通过高精度定时器(一个 3.25M 的timer)来统计 kobject_uevent 的时间花费:
还没有进入用户空间时,内核调用了 kobject_uevent 244次, 平均每次 289us, 总共70ms(由于每次需要调用并不存在的 /sbin/hotplug, 时间比较长。
进入用户空间后,调用 udevtrigger, 开始15次 kobject_uevent 调用平均每次 6249us, 总共93ms (很奇怪,需要深入研究一下)。
然后 181 次 kobject_uevent 调用平均每次 47us, 总共 8ms。
优化方案:
考虑到:
还没有进入用户空间时发出的 uevent看似丢失了!可以不发出
/sbin/hotplug 在使用 netlink 时永远没有必要调用!可以删除
我们可以:
删除调用/sbin/hotplug的代码
在uevent_helper 非空时不真正发出 uevent
这样,在进入用户空间之前,我们的uevent机制不会做任何事情,只有用户空间调用
echo "" > /sys/kernel/uevent_helper
后, uevent 才会被真正发送到netlink.
实践证明系统运行良好。
udev 参考文档
Writing udev rules
http://reactivated.net/writing_udev_rules.html
udev文件系统的使用和基本工作原理分析
http://blog.csdn.net/colorant/archive/2008/01/09/2031721.aspx
udev的实现原理
http://blog.csdn.net/absurd/archive/2007/04/27/1587938.aspx
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/zjujoe/archive/2008/09/27/2986634.aspx
前言
这两天遇到一些 udev 的问题, 顺便阅读了一下文档(见参考文档), 基本了解了 udev 的机制。嵌入式系统性能很重要,于是对内核这一块进行了性能方面的研究。
内核大概20多处会调用了 kobject_uevent 函数发送 KOBJ_ADD / KOBJ_REMOVE 等事件。其中我们最关心的就是在device_add/device_del 中向用户空间发送设备的添加、删除信息。
kobject_uevent 直接调用 kobject_uevent_env 函数完成功能,我们先分析一下该函数的流程。
kobject_uevent_env调用流程 (内核版本 2.6.21)
kobject_uevent_env首先搜索 kobject 所属的 kset, 获得kset->uevent_ops,类型为kset_uevent_ops (系统一共有block_uevent_ops memory_uevent_ops device_uevent_ops class_uevent_ops module_uevent_ops )这几大类 kset_uevent_ops,我们这里主要看device_uevent_ops。
如果 uevent_ops 有 filter 成员函数, 则调用该函数,如果filter函数返回非0,则失败,结束流程。device_uevent_ops 的 filter函数为 dev_uevent_filter, 它的过滤条件为该设备的总线(bus) 或者类 (class) 非空。
为 envp分配一个大小为 32 的数组, 用于存储环境变量指针,为 buffer 分配一个大小为 2048 的数组,用于存储环境变量内容。
初始化环境变量, 包括 HOME PATH ACTION DEVPATH SUBSYSTEM 等
如果 uevent_ops 有 uevent 函数,则调用该函数,如果uevent函数返回非0,则失败,结束流程。device_uevent_ops 的 uevent 函数为dev_uevent,它的流程为:
添加主次设备号到环境变量
添加 driver 的名称到环境变量
如果设备所属总线 (dev->bus)有 uevent函数, 则调用它。如失败,结束流程
如果设备所属类 (dev->class)有 uevent函数,则调用它。如失败,结束流程。(象函数_request_firmware ()中,有两次调用kobject_uevent函数,其中第一次在class 的 uevent函数firmware_uevent中,测试 FW_STATUS_READY位失败而返回)。
如果设备所属类型 (dev->type)有 uevent函数, 则调用它。如失败,结束流程. (搜索了一下, 这个field 在整个内核里基本没有使用)
注意每个 uevent 函数都有机会添加环境变量以及出错返回,结束uevent传递。
递增 uevent 序列号uevent_seqnum(可以通过 cat /sys/kernel/uevent_seqnum 查看)。
如果定义了 CONFIG_NET 通过 netlink 将事件以及环境变量发送出去。
如果uevent_helper 非空, 则调用该函数。uevent_helper 的缺省值为: "/sbin/hotplug" 应该在用户层调用:echo "" > /sys/kernel/uevent_helper 来取消该此调用。
性能数据统计
我们通过高精度定时器(一个 3.25M 的timer)来统计 kobject_uevent 的时间花费:
还没有进入用户空间时,内核调用了 kobject_uevent 244次, 平均每次 289us, 总共70ms(由于每次需要调用并不存在的 /sbin/hotplug, 时间比较长。
进入用户空间后,调用 udevtrigger, 开始15次 kobject_uevent 调用平均每次 6249us, 总共93ms (很奇怪,需要深入研究一下)。
然后 181 次 kobject_uevent 调用平均每次 47us, 总共 8ms。
优化方案:
考虑到:
还没有进入用户空间时发出的 uevent看似丢失了!可以不发出
/sbin/hotplug 在使用 netlink 时永远没有必要调用!可以删除
我们可以:
删除调用/sbin/hotplug的代码
在uevent_helper 非空时不真正发出 uevent
这样,在进入用户空间之前,我们的uevent机制不会做任何事情,只有用户空间调用
echo "" > /sys/kernel/uevent_helper
后, uevent 才会被真正发送到netlink.
实践证明系统运行良好。
udev 参考文档
Writing udev rules
http://reactivated.net/writing_udev_rules.html
udev文件系统的使用和基本工作原理分析
http://blog.csdn.net/colorant/archive/2008/01/09/2031721.aspx
udev的实现原理
http://blog.csdn.net/absurd/archive/2007/04/27/1587938.aspx
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/zjujoe/archive/2008/09/27/2986634.aspx
相关文章推荐
- Udev 内核机制(kobject_uevent) 性能优化
- Udev 内核机制(kobject_uevent) 性能优化
- Udev 内核机制(kobject_uevent) 性能优化
- Udev 内核机制(kobject_uevent) 性能优化
- Udev 内核机制(kobject_uevent) 性能优化
- Udev 内核机制(kobject_uevent) 性能优化
- Udev 内核机制(kobject_uevent) 性能优化
- Udev 内核机制(kobject_uevent) 性能优化 .
- H5 缓存机制浅析 - 移动端 Web 加载性能优化【转载保留】
- 内核同步机制-优化屏障和内存屏障
- Hibernate 性能优化_转载
- MySQL性能优化的21个最佳实践(转载)
- 数据库相关文章转载(1) MySQL性能优化之参数配置
- Android群英传》读书笔记 (4) 第八章 Activity和Activity调用栈分析 + 第九章 系统信息与安全机制 + 第十章 性能优化
- 转载 优化网站性能 提高网站速度访问速度的14条实践
- spark内核揭秘-14-Spark性能优化的10大问题及其解决方案
- 数据库性能调优——sql语句优化(转载及整理)
- 【转载】HBase 数据库检索性能优化策略
- 前端工程师前端性能优化及技巧分享--本文转载自360问答
- C语言嵌入式系统编程修炼之性能优化(转载)