On Sat, 4 Oct 2008, Mitch Bradley wrote: > Deepak Saxena wrote: >> On Oct 03 2008, at 07:34, Mitch Bradley was caught saying: >> If >> it is stored deocompressed to begin with on the filesystem, we >> can simply read it into mem from flash and run. This would require >> a few extra MiB of flash. Granted, reading from flash is >> slower than reading from memory, so we may not see a a net >> benefit. Easy enough to test... >> > > Some rules of thumb for OLPC: > > a) Memory copy goes at about 500 MB/sec (so can be neglected in this case) > b) zlib decompression goes at about 3 MB/sec for typical code (2:1 > compression ratio) (Over the complete filesystem, JFFS2's automatic > zlib compression gets you about 3:2 space savings, because of various > overhead factors). > c) Raw FLASH read time maxes out at 20 MB/sec. But you don't get that > speed from the filesystem; JFFS2 is good for between 5 and 10 MB/sec. > > Considering all the intricacies of JFFS2, my best guess is that it's > going to be close to a wash whether the kernel + initrd is stored in > compressed or uncompressed form. > > OTOH, if the kernel + initrd were in a separate partition in e.g. romfs > format, where OFW could just blast them into memory without doing JFFS2 > node processing, we could probably get close to the 20 MB/sec speed. > > Another holdup is the time it takes to do the hash calculation for > security checking. That costs a couple of seconds. Ivan and I worked > pretty hard to minimize that time, choosing one of the faster hash > functions.
can you do the hash as you copy it? it should be pretty close to free at that point (since the CPU is waiting for memory/flash access it can do the hash calculationwhen it would otherwise be stalled) David Lang _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel