JFFS2 speed question

[Frederic Giasson]

Hi,

I have noticed such a problem and began to address it bug I lacked of time
and I have been moved on another project.  

When I copyied large files under the same conditions you described, I
experienced quite some lag. But what really appeared to me to be a serious
problem is the following: When I copy a large file to JFFS2 ( which fills it
to about 95% disk usage ), then I reboot my platform and remount JFFS2, the
large file is still there of course.  But if I erase it and try to copy it
back, the rm command never returns.  It seems that there is a problem with
the garbage collector.  The garbage collector could be spinning around
constantly moving data.  

Hope this will give you a hint.

Frédéric Giasson





|-----Original Message-----
|From: simon gittins [mailto:simon__gittins at hotmail.com]
|Sent: Tuesday, September 11, 2001 12:50 AM
|To: linux-mtd at lists.infradead.org
|Subject: JFFS2 speed question
|
|
|Hi
|
|I've been looking at the performance of jffs2 when under high stress 
|(copying large files when fs is largely full).  Looking at the 
|kernel debug 
|messages, I've noticed fairly frequent 3-5 second gaps.  I'm 
|fairly new to 
|jffs2, but I did some hacking in the source and found:
|
|1. The 5 second wait times are generally started by a request 
|for a file 
|semaphor, and are always terminated by kupdated, (which calls 
|write_super?). 
|  kupdated sleeps for 5 seconds (on my 2.4.9 kernel) between 
|iterations.  Am 
|I right in thinking that this is a large bottleneck in the 
|system?  I can 
|manually 'speed it up' by running the following shell commands 
|during a 
|block time:
|    kill -STOP 7; kill -CONT 7 #where 7 is the pid of kupdated
|Can we minimise the dependence of jffs2 on kupdated?
|
|
|2.  Semaphors appear to be held during the execution of 
|schedule().  While I 
|have not delved deeply enough to fully understand the 
|algorithms in place, a 
|plethora of printk's seem to suggest that there are occasions where a 
|process (gc or user process) would hold the semaphor and go to 
|sleep (via 
|schedule) without releasing the semaphor.  The other process 
|would then pick 
|up the execution, and (eventually) try to access the semaphor 
|and fall into 
|a sleep as well.  This appears to often cause the symptoms in 
|(1), where 
|both processes are napping until kupdated comes along.
|
|Am I on the right track?
|
|Is there any development time being spent looking at the 
|performance issue 
|(apart from mine)?
|
|
|
|I am working with 3 September CVS code on a 2.4.9 kernel.  I 
|am using a 
|pseudo flash device with mtdram to perform my tests.
|
|Regards
|Simon Gittins
|
|
|
|_________________________________________________________________
|Get your FREE download of MSN Explorer at 
|http://explorer.msn.com/intl.asp
|
|
|
|______________________________________________________
|Linux MTD discussion mailing list
|http://lists.infradead.org/mailman/listinfo/linux-mtd/
|