[LEDE-DEV] What optimizations does low-end MIPS userspace need?

[Martin Tippmann]

On Sat, Apr 15, 2017 at 1:00 AM, Jay Carlson <nop at 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