All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bernhard Priewasser <priewasser@gmail.com>
To: MTD mailing list <linux-mtd@lists.infradead.org>
Subject: How to determine MTD/JFFS2 RAM consumption
Date: Wed, 12 Oct 2005 12:34:51 +0200	[thread overview]
Message-ID: <434CE6CB.9040509@gmail.com> (raw)

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

             reply	other threads:[~2005-10-12 10:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-12 10:34 Bernhard Priewasser [this message]
2005-10-12 13:46 ` How to determine MTD/JFFS2 RAM consumption Zoltan Sogor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=434CE6CB.9040509@gmail.com \
    --to=priewasser@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.