On Sat, Apr 15, 2017 at 1:00 AM, Jay Carlson <n...@nop.com> wrote: > I’ve been fooling around with various userspace toolchain hacks for mips, > trying to make things faster globally. But then I realized: I don’t know what > “faster” is. Or what “better” is, in general.
[...] > There was a very useful discussion about free space on jffs2 in terms of > erase blocks, since some machines are out of them. 32M/4M machines are on the > chopping block, right? So anything that can get the squashfs down to an erase > block boundary or two might be a win. For example, I got musl building in > mips16 mode, and it was a lot less hack-y than I expected. But mips->mips16 > executables in squashfs are not that much smaller. libc went from 600k to > 450k, but after xz -0, it was 236k -> 211k. All that for 15k in squashfs. Of > course, that’s still 150k less code to be faulted in. musl, busybox + all the the other userland could be build with link time optimisation (-flto). Not everything compiles or works with it, but after compression another 80kbyte were free on the default image. This might make things a little bit faster but I didn't test memory usage or speed. Gains from busybox or musl were minimal (not more than 20kbyte compressed). Another hack is to reduce the squashfs fragment cache size[1] and try bumping up the squashfs block size from 256. In testing this gave some more free memory on 32MByte devices, even with 512 block size but I don't have any hard data. Might be worth a look if you run out of other options. regards Martin https://gitlab.bau-ha.us/weimarnetz/firmware/blob/master/patches/801-fragment-cache-size.patch _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
