In any analysis, please don't bother with the B1 and B2 configurations as those platform profiles will not be an option in the production machines.
-walter On 7/8/07, Mitch Bradley <[EMAIL PROTECTED]> wrote: > Andres Salomon wrote: > > ... > > > > Implementation questions: > > > > I'm not going to concern myself with our B1s, for they have more ram > > and less nand. Our B2s have 128MB of ram, and 512MB of nand; B3s and > > up have 256MB of ram, and 1GB of nand. We need to figure out just > > how much space we'd need to set aside in a snapshot partition for STD. > > I'm not sure what would be required from the OFW side; Mitch? > > First-order swag: > > You need 256MB of disk to store 256MB of RAM, in the nothing-fancy scenario. > > Second-order swag: > > Machine code compresses about 2:1 with gzip, so if the memory were full > of code, you would need about 128MB of disk for 256 MB of RAM. OFW > already includes a gunzip-compatible decompressor which is reasonably > fast (written in C, runs from cached memory). It would be easy enough > to add either LZMA , LZO, or QuickLZ. It's likely that we could overlap > the compression/decompression with NAND access, so the speed penalty > would be minimal. > > Third-order swag: > > The memory is likely to be significantly more compressible than random > machine code, due to the likely prevalence of sparsely-encoded data. So > maybe the average compression in practice would be 3:1 or 4:1 or even > better. But we would might need to allocate space for the worst case. > > Fourth-order swag: > > It wouldn't be necessary to save read-only code ("text" pages) to the > save area; just mark those pages "not present" and save the information > necessary to page them back in. But that would probably make the resume > slower, because of the JFFS2 operations necessary to resolve all those > page-in references. The firmware part of the resume would be faster, > but the overall suspend/resume process might take longer (or maybe not; > you trade not having to write the data out on the way down for having to > do more work on the way up). > > The firmware part of this shouldn't be particularly difficult if we can > make the save format reasonably straighforward. It could get more > difficult if we run into enough examples of "somebody has already done > this so we have to use their existing solution even though it is massive > overkill for our situation". > > > _______________________________________________ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- Walter Bender One Laptop per Child http://laptop.org _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel