Skip to contentSkip to conversation

Testing JFFS2 using mtdram

DISCUSSION Bernhard Priewasser 5 participants 6 messages Aug 22, 2005 – Aug 23, 2005 Memory technology devices (MTD)

lore
Share & tools
lore
#0 lore raw

Good morning,

I'm going to run some performance and stability testing on JFFS2. Using mtdram makes basic testing issues very comfortable. My question is how far mtdram can substitute a "real" flash (not for absolute measurement of course, only comparisons)? Am I right with my first approach:
read operations - yes
write operations - no?

Regards,
Bernhard Priewasser

#1 lore raw

Hello Bernhard,

Quoted 7 lines

I'm going to run some performance and stability testing on JFFS2. Using mtdram makes basic testing issues very comfortable. My question is how far mtdram can substitute a "real" flash (not for absolute measurement of course, only comparisons)?
Am I right with my first approach:
read operations - yes
write operations - no?

mtdram emulates NOR flash (both read and write operations), but does not emulate delays. You can test stability with it, but for performance I suggest Artem's nand simulator. It's included in the official MTD. It can emulate delays and ceratinly you can test the NAND functionalities of JFFS2, too.

Ferenc

#2 lore raw
Quoted 5 lines · Ferenc Havasi

mtdram emulates NOR flash (both read and write operations), but does not emulate delays. You can test stability with it, but for performance I suggest Artem's nand simulator. It's included in the official MTD. It can emulate delays and ceratinly you can test the NAND functionalities of JFFS2, too.

Albeit you cannot emulate > 128 MB flashes (just because 128 MB is the vmalloc()'s limit). This may be fixed, I just did not bother. And I never used that delays, just added them to make nandsim look cooler (kidding) :-)

Signature · 3 lines
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
#3 lore raw
Quoted 3 lines · Artem B. Bityuckiy

Albeit you cannot emulate > 128 MB flashes (just because 128 MB is the vmalloc()'s limit). This may be fixed, I just did not bother.

I did that for ramtd. Allocate an array of pointers and then lazily allocate memory for those pointers. Moves the limit to 128G on i386. For even bigger flashes, a 2-3 level tree would work, but I rarely need more than a gig.

Jörn

Signature · 2 lines
Invincibility is in oneself, vulnerability is in the opponent.
-- Sun Tzu
#4 lore raw
Quoted 2 lines

I did that for ramtd. Allocate an array of pointers and then lazily allocate memory for those pointers.

Did anyone do something similar for mtdram too?
I tried it quick & dirty, but didn't work :-) If there's a solution for mtdram I would be grateful, otherwise I had to try further. mtdram's/vmalloc()'s total size limit indeed is rather low for extensive testing.

Regards,
Bernhard

#5 lore raw
Quoted 9 lines · Bernhard Priewasser
Quoted 3 lines

I did that for ramtd. Allocate an array of pointers and then lazily allocate memory for those pointers.

Did anyone do something similar for mtdram too?
I tried it quick & dirty, but didn't work :-) If there's a solution for mtdram I would be grateful, otherwise I had to try further. mtdram's/vmalloc()'s total size limit indeed is rather low for extensive testing.

Ramtd was supposed to replace mtdram. There were the usual problems with parameter parsing, and writing a new one was easier than fixing the old.

Jörn

Signature · 2 lines
He who knows that enough is enough will always have enough.
-- Lao Tsu