How to determine MTD/JFFS2 RAM consumption

How to determine MTD/JFFS2 RAM consumption

[Bernhard Priewasser]

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:
 > 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):
 > 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_i                1     11    340   11

10 files (<<4KiB) written
 > 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_i               11     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

Re: How to determine MTD/JFFS2 RAM consumption

[Zoltan Sogor]

Hi!

Bernhard Priewasser wrote:

> - Why are there 64 jffs2_raw_node_refs after 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.

> - Why are there 103 jffs2_raw_node_ref after 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)

> - What about jffs2_node_frag and jffs2_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