How to determine MTD/JFFS2 RAM consumption
Hi all,
I'm trying to measure some memory requirements and would be glad if I got some clues from the experts.
- "Static" requirements
Memory needed to run/use MTD/JFFS2 at all.
I don't wanted to dig as deep into the source code to analyze some malloc()s, so I tried a very very simple thing like this:
cat /proc/meminfo
insmod jffs2.ko
cat /proc/meminfo
I really don't know if this method is adequate at all. Is it?...
- "Dynamic" requirements
RAM allocated due to write operations on mounted JFFS2.
According to JFFS white paper there should be a struct jffs2_inode_cache and a struct jffs2_raw_node_ref in memory for each (i)node after all. structs jffs2_raw_inode, jffs2_raw_dirent, jffs2_full_dnode are freed after creating/writing around.
struct jffs2_inode_info is reclaimed under pressure.
(What about struct jffs2_node_frag?)
Thus, memory consumption can be calculated out of the size of the two structs jffs2_inode_cache and jffs2_raw_node_ref. Right?...
- Some questions to the "cat /proc/slabinfo | grep jffs" below:
JFFS2 is existing, e.g. .ko inserted:
Quoted 8 lines
jffs2_inode_cache 0 0 24 156 jffs2_node_frag 0 0 28 135 jffs2_raw_node_ref 0 0 16 226 jffs2_tmp_dnode 0 0 12 290 jffs2_raw_inode 0 0 68 58 jffs2_raw_dirent 0 0 40 96 jffs2_full_dnode 0 0 16 226 jffs2_i 0 0 340 11
JFFS2 mounted (empty):
Quoted 8 lines
jffs2_inode_cache 1 156 24 156 jffs2_node_frag 0 0 28 135 jffs2_raw_node_ref 64 226 16 226 jffs2_tmp_dnode 0 0 12 290 jffs2_raw_inode 0 0 68 58 jffs2_raw_dirent 0 0 40 96 jffs2_full_dnode 0 0 16 226
jffs2_i1 11 340 11
10 files (<<4KiB) written
Quoted 8 lines
jffs2_inode_cache 11 156 24 156 jffs2_node_frag 10 135 28 135 jffs2_raw_node_ref 103 226 16 226 jffs2_tmp_dnode 0 0 12 290 jffs2_raw_inode 0 0 68 58 jffs2_raw_dirent 0 0 40 96 jffs2_full_dnode 10 226 16 226
jffs2_i11 11 340 11
- Why are there 64 jffs2_raw_node_refs after mounting an empty JFFS2?
- Why are there 103 jffs2_raw_node_ref after writing 10 (small) files?
- What about jffs2_node_frag and jffs2_full_dnode?
- What about the num_objs numbers (156, 135, 226,...)?
Thank you very much, Regards,
Bernhard
Hi!
Quoted 1 line · Bernhard Priewasser
- Why are there 64
jffs2_raw_node_refsafter mounting an empty JFFS2?
If you are using NOR memory then there is a cleanmarker node in the begining of every jeb and the scan process allocates a raw_node_ref for it.
Quoted 1 line
- Why are there 103
jffs2_raw_node_refafter writing 10 (small) files?
If you write a new file to the flash then it allocates a inode, dentry and an other inode. Every dentry has an inode number to which it belongs to, that's why jffs2 allocates the inode first and after then the dentry. The second inode contains the writed data (if the compreessed size of the data and the inode header is smaller than 4k ). 64 + 30 = 94
(What is about the other 9? I don't know exactly but if you send us the testcase then maybe we can tell more)
Quoted 1 line
- What about
jffs2_node_fragandjffs2_full_dnode?
Jffs2 builds up the full inode data by fragments (as on flash) and builds a red-black tree (using the version number as key). jffs2_node_frag stores the size of the fragment and the offset of the fragment. Offset is the distance from the begining of the file. jffs2_full_dnode is an extension of raw_node_ref. Write_dnode returns a full_dnode pointer, it contains the offset and the size of the written data and a pointer to a raw node. From this information jffs2 can build up the new fragment and add it to the fragment tree.
Zoltan