On Thu, 29 Sep 2005, Stephen Samuel wrote: > At a quick guess (and this is COMPLETELY a guess), the phone > runs the applications direct off of the ROMfs, but if it > thinks they're being run from an alien fs (unionfs), it's > going to be 'tricked' into loading them directly into RAM, > (possibly even the flash card), and possibly having to swap them. > > I have no idea as to how you'd test that thesis. >
The phone uses the standard linux elf loader, and runs from a cramfs. No special loader was added. As far as I understand, it means code is loaded into ram anyway. I don't know if Linux even supports running executables in-place from a cramfs. Anyone knows if its possible ? Anyway, this probably isn't the problem. See the previous message I posted. Memory consumption with unionfs started before applications and with unionfs started after applicaions appear to be quite similar. The only difference is that the applications (and shared-objects) are mapped from unionfs rather than the original cramfs. In the meantime, I reflashed the phone with a two-stage unionfs. In the first stage, I mount it (as early as possible, before rc files are executed) but I don't pivot_root it. Instead, I mount --bind some dirs from it (such as /etc) so internal applicaions use my modified configuration. At the second stage, an S99* script from the modified /etc will do the pivot_root (after all applications are loaded) and lazy-umounts the --bind mounts. Seems to do the trick but I'd still like to find out why unionfs has that effect on code executed from it. Its quite possible that by running it in such a resource-constrained environment I encountered some unionfs bug that went undetected on faster systems. _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
