liwen01 2023.10.01
前言
在嵌入式系统中,内存是比较紧缺的资源,特别是在消费类产品中, 为了节省成本,一般都会将硬件资源应用到极致。在开发过程中,就经常会遇到,运行内存(RAM
)就还差一点,但就是不够用的情况,比如:
- 需要在原系统上添加一个小算法
OTA
只能将固件放到内存上时- 需要动态分配比较大的空间
- 需要放置一些比较大的临时文件
如果你原来设备内存已经使用到90%
甚至更高,要实现上面功能,大概率会影响系统的整体性能,甚至会出现系统异常。那该怎么办?
在不考虑硬件增加RAM
大小的情况下,软件上还有没有其它的方式,可以挤出一点点空间呢?答案是可以的,但是需要综合评估带来的问题和风险。
这里以君正T31ZC
为实例,来介绍它的内存使用情况,以及如何挤出更加多的内存空间
(一)内存使用情况分析
T31ZC
是一款基于MIPS
架构的主处理器,上面集成了512Mbit
的DDR2
内存,使用的是linux
操作系统。
(1)物理内存分布
512Mbit
的物理内存,也就是64MByte
,在实际使用的时候,它被划分为了两块,rmem
和 mem
rmem
用于多媒体,比如音视频编码、裁剪、OSD等功能mem
是用于linux
系统内存
它通过tag
部分的cmdline
来设置
[root@Zeratul:~]# cat /proc/cmdline
console=ttyS0,115200n8 mem=40M@0x0 rmem=24M@0x2800000 root=/dev/ram0 rw rdinit=/linuxrc mtdparts=jz_sfc:256K(boot),352K(tag),5M(kernel),6M(rootfs),2560K(recovery),1440K(system),512K(config),16M@0(all) lpj=6955008 quiet senv;[HW];init_vw=1920;init_vh=1080;nrvbs=2;mode=0;eenv; lzo_size=5907415 rd_start=0x80600000 rd_size=0xd35c00
[root@Zeratul:~]#
这里我们看到40M
分配给了linux
系统,24M
分配给了多媒体。
通过 dmesg
命令可以看到更多内存的使用情况
rd_start=0x80600000 rd_size=0xd35c00
这个是用来存放根文件系统的起始位置,以及这个空间的大小
Memory: 20680k/40960k
40960K
是linux
系统可使用的总大小,也就是上面设置的40MB,20680k
是系统实际可以使用的内存
剩下的 40960K - 20680k = 20280K
内存到哪里去了?
3868k kernel code, 20280k reserved, 1052k data, 196k init, 0k highmem
一部分是给内核使用,包括内核代码段、数据段、以及 init
段
剩下的20280k - 3868K -1052K - 196K = 15164K
这剩下的1516K
是预留给ramfs
使用的
(2)mem使用情况
linux
系统启动后,不运行其它的应用程序,我们查看的内存使用情况如下:
cat /proc/meminfo
可用的实际物理内存大小还剩余12872 kB
分配给linux
系统使用的内存有40M
,但是应用程序都还没开始运行,内存就只剩下12872K
,内存都到哪里去了!
总结归纳如下:
- 总物理内存
64M
,24M
分配给了多媒体,40M
分配给了linux
系统
总大小 | 多媒体内存 | linux系统 |
---|---|---|
64M | 24M | 40M |
linux
系统内存中,可使用的内存为20680k
,预留的内存为20280k
linux系统 | available | reserved |
---|---|---|
40960k | 20680k | 20280k |
linux
系统中可使用的内存,内核模块加载,缓冲缓存等系统服务占用7768K
,剩余的为应用可使用的内存
available | MemFree | modules/others |
---|---|---|
20680k | 12912k | 7768K |
linux
系统中预留的内存,主要是预留给kernel
和根文件系统,其中kernel
中主要有代码段,数据段,init
段。剩下的主要是根文件系统占用的空间。
reserved | kernel code | kernel data | kernel init | ramfs | others |
---|---|---|---|---|---|
20280k | 3868K | 1052K | 196K | 13527K | 1637K |
(二)优化方向
从上面的分析来看,可以优化的方向有:
- 减少模块加载,系统服务
kernel
优化rootfs
优化
(1)减少模块加载,系统服务
这个可优化的空间有限,这里不做详细讨论,可以通过命令查看实际模块加载情况:cat /proc/modules
(2)kernel 优化
将内核的调试信息去除掉,可以在menuconfig
中取消 Load all symbols for debugging/ksymoops
选项,这里可以省出少量的空间
(3)rootfs 优化
从上面的分析,我们看到为ramfs
预留的空间为13527K
,这是个非常大的空间。从启动cmdline
中我们看到Flash
的分区信息如下:
256K(boot),352K(tag),5M(kernel),6M(rootfs),2560K(recovery),1440K(system),512K(config),16M@0(all)
1. flash为rootfs预留的空间为6M,而内存为rootfs预留的是13527K,为何相差如此之大?
主要的原因是我们rootfs
在烧录到Flash
的时候是压缩过的,在加载rootfs
的时候,首先是将rootfs
从Flash
中读取出来,再解压到内存指定的地址去,然后再将解压后的rootfs
挂载成ramfs
文件系统加载起来。
rootfs
的打包命令如下:
cd ./_rootfs_camera
find . | cpio -H newc -o > ../rootfs_camera.cpio
cd ..
lzop -9 -f rootfs_camera.cpio -o rootfs_camera.cpio.lzo
./mark_rootfs_pc rootfs_camera.cpio.lzo
- 将
_rootfs_camera
目录下的所有文件归档到上一目录的rootfs_camera.cpio文
件中 - 使用
lzop
命令使用最高等级(9)的压缩方式把rootfs_camera.cpio
压缩到rootfs_camera.cpio.lzo
文件,-f
表示强制执行,如果rootfs_camera.cpio.lzo
已经存在则覆盖它 mark_rootfs_pc
是用来更新rootfs_camera.cpio.lzo
的实际文件大小,实际是将压缩后的文件大小写入到rootfs_camera.cpio.lzo
的最开始位置(4字节)。
2. 为什么要使用ramfs文件系统?
ramfs
适合用于临时存储、临时文件、内核模块载入等临时性应用,其中数据不需要长期保存的场景,它是linux
内核中的虚拟文件系统,不需要指定特定的挂载选项。
优点有:
- 快速读写操作
- 零延迟
- 轻量级
- 易于创建和销毁
缺点有:
- 不具备持久性
- 内存限制
- 不适合大型文件
- 需要足够的内存
君正T31ZC
是属于低功耗SOC
,实时性,快速启动要求比较高。一般应用场景是有另外的MCU
来控制它上下电,有事件触发的时候,SOC
上电处理事件,事件处理完成后,SOC
下电,只留MCU
工作,以达到省功耗的目的,所以使用ramfs
也是合理的选择。
官方手册上的建议是这样的:
rootfs中只存放对快起有要求的必要程序和库文件,如果对快起没有要求的程序或库文件建议放到 system 分区,以达到快速启动和节省内存的目的。
(三)另类解决方案
(1)问题分析
根据上面的分析,如果系统使用的是ramfs
,优化空间最大的就是根文件系统,减小根文件系统的大小可以直接节省内存。
上面官方给的建议中需要面对另外一个问题,就是需要在应用程序启动之后,再去system
分区使用dl_open
加载所需要的动态库。如果你程序主要使用的是静态库,那这种方式就达不到想要的效果。
查看rootfs
文件系统里面的内容,占用空间大的,一个是stone
目录,另外一个是lib
目录。
./stone
目录下放置的是需要运行的main
程序./lib
目录下放置的主要是一些动态库,ko
驱动文件,以及一个wifi
使用的bin
文件
-rwxrwxr-x 1 biao biao 6.2M Oct 15 18:14 main
-rwxrwxrwx 1 biao biao 1003K Aug 21 10:04 cywdhd.ko
-rwxrwxrwx 1 biao biao 404K Aug 21 10:04 fw_bcm43438a1.bin
(2)解决方案
main
执行程序在启动的时候就执行
./etc/init.d/rcS:/stone/main &
wifi
驱动也是在启动的时候被加载
insmod /lib/modules/cywdhd.ko firmware_path=/lib/firmware/fw_bcm43438a1.bin nvram_path=/lib/firmware/nvram.txt iface_name=wlan0
是否可以这样:
在启动的时候,main 执行文件,cywdhd.ko驱动,驱动固件fw_bcm43438a1.bin被加载完之后,就把它们删除,以达到释放内存的目的?
因为这些文件都是放置在内存上,删除它们并不会影响Flash
中的文件,下次上电可以重新从Flash
中读取出来,删除它们也确实是可以释放一部分内存。
以我上面的例子,删除 main
文件就可以释放6.2M
的空间,确实也是可以达到释放内存的目的。
但是,这样操作是否有风险?
(四)删除ELF文件是否有影响
我们知道,程序运行是被段页式加载到内存的,那要怎么知道在删除main
程序执行文件的时候,main
程序里面的内容已经被全部加载到内存中去了呢?
同样,删除ko
文件和bin
固件数据文件的时候同样会遇到相同的疑问。
(1)删除 cywdhd.ko 驱动
通过 cat /proc/modules
命令可以查看模块的加载情况
[root@Zeratul:bin]# cat /proc/modules | grep cywdhd
cywdhd 671712 0 - Live 0xc0215000
jzmmc 17113 1 cywdhd, Live 0xc010f000
mmc_core 90139 3 mmc_block,cywdhd,jzmmc, Live 0xc00e5000
我们看到 cywdhd.ko
被加载到内存的0xc0215000
这个地址,Live
表示已经加载到内核并且在在运行。671712
表示它的大小。
为什么我们前面看cywdhd.ko 大小是1003K ,加载到内核中去却只剩下67171 ?
我们使用 file
命令查看cywdhd.ko
文件信息,发现它是ELF
文件格式,并且是not stripped
,也就是它里面还包含一些调试信息和调试符号表等内容
biao@ubuntu: file cywdhd.ko
cywdhd.ko: ELF 32-bit LSB relocatable, MIPS, MIPS32 version 1 (SYSV), BuildID[sha1]=a00e1928dd77ac04bb813b22cd485156f3392741, not stripped
strip
处理之后,文件大小变成了657788
biao@ubuntu: mips-linux-uclibc-gnu-strip cywdhd.ko
biao@ubuntu:ll
-rwxrwxrwx 1 biao biao 657788 Oct 15 19:42 cywdhd.ko
综合上面信息,我们可以大致判断删除cywdhd.ko文件是没有风险的。
还有一种确认方式是:通过查看 /proc/kallsyms
文件信息
/proc/kallsyms
包含了内核符号表信息,其中包括已加载模块的地址范围。如果模块的地址范围包括整个模块,那么它通常已经完全加载到内存中。
(2)删除fw_bcm43438a1.bin固件
fw_bcm43438a1.bin
是作为cywdhd.ko
驱动的一个固件被加载到内核上的,至于它是什么时候使用,或者说是否一次全部加载到内存上了,应该取决于cywdhd.ko
驱动
因此我个人认为删除fw_bcm43438a1.bin
是会有比较大的风险的
(3)删除main程序
在Linux
系统中, 执行文件,动态库,驱动文件都是属于ELF
文件格式。ELF
文件里面分很多段,常见的有代码段,数据段,BSS
段。
可以使用命令 readelf -S your_program
来具体查看
我们看到代码段的大小是0x46a6b0
,在很多操作系统中,为了节省内存空间,都是使用动态加载的方式,也就是段页式加载方式。
根据局部性原理,一般程序在执行的时候,都是将当前执行位置附近的数据加载到内存上运行。
但是对于ramfs
文件系统,因为它已经是被全部加载到内存上了,那在它上面的main
文件,在执行的时候,它是一次性加载(全局加载)还是按需加载(段页式加载)呢?
如果它是在运行的时候一次性加载到内存上,那么,在它运行之后,把main
文件删除是没有风险的,否则会引入系统风险。
对于执行文件在ramfs
文件系统上的加载,暂时没有找到更详细的介绍资料,熟悉这一领域的同学可以给点建议。
(五)手动释放内存
可以使用命令手动释放内存:
echo 1 > /proc/sys/vm/drop_caches
关于drop_caches
的介绍,可以通过 man proc
的介绍来了解,这里不做过多说明
(六)结尾
综合上面介绍的内容,在嵌入式Linux
系统内存不足的情况下,可以使用下面几种方式进行优化
- 将
kernel
的调试信息符号表去除,减少内核镜像文件大小 - 将文件系统上的
ELF
文件(包括执行文件、动态库和ko
驱动文件)strip
处理,去除多余的信息 - 将动态库放置到其它分区上,程序运行后再通过
dl_open
来加载 - 执行文件或是驱动文件,在使用过后把它们删除(可能存在风险)
- 手动释放内存
具体使用哪种方式,可以根据实际使用情况进行评估和选择。
以上如有分析错误的地方,欢迎批评指正。