On Sun, Aug 11, 2019 at 10:36 AM <mcatanzaro(a)gnome.org> wrote:
> This seems like a distraction from the real goal here, which is to
> ensure Fedora remains responsive under heavy memory pressure,

I think this is an overwhelmingly important point, and as somebody
regularly working with ARM machines with tiny amounts of RAM, it is of
considerable interest to me.
I typically use CentOS because stability is important to me, but most
worthwhile things filter to there, so I hope what I'm about to say is not
_too_ deprecated.

1) Compile options
>From what I can tell from rpm macro options, default on C7 seems to be -O2.
-Os seems to help in most cases.
Adding -ffunction-sections -fdata-sections to defaults can help
considerably in producing smaller binaries, and is not the default.
Linking with -Wl,--gc-sections helps a lot and is not the default
Extensive stripping seems to already be the default (--strip-unneeded,
removal of .comment and .note sections)

2) Runtime condiguration
Default stack size is 8192 (ulimit -s). This unnecessarily eats a
considerably amount of memory. I have yet to see anything that actually
experiences problems with 1M.

3) zram
This was mentioned earlier in the thread, and on most of my systems, memory
constrained or otherwise, unless I have an overwhelming reason not to, I
run with zram swap equal in size to RAM with lz4 compression and
vm.swappiness=100. I typically see compression ratios between 2:1 and 3:1
in zram, so on a system with, say, 10GB of RAM, it would provide 10GB of
very fast swap at a cost of 3-5GB of RAM. This seems like a favourable
trade off, especially on systems with extremely constrained RAM (e.g. ARM
devices with 512MB of RAM).

I'm sure there is more that can be done, but this seems like a good start
as far as the cost / benefit is concerned.
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to