On Sun, Aug 18, 2019 at 2:06 PM Hans de Goede <hdego...@redhat.com> wrote:
> Hi, > > On 18-08-19 13:33, Gordan Bobic wrote: > > On Sun, Aug 11, 2019 at 10:36 AM <mcatanzaro(a)gnome.org < > http://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. > > I don't think it is likely that Fedora will switch to -Os > It is not my place to argue about whether it will. The thread was asking for things that might contribute toward alleviating the memory pressure problem. This can make a fairly dramatic difference and it would contribute toward alleviating the problem because smaller binaries mean less to mmap(). > > 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 > > These OTOH are interesting I know that e.g. uboot combines these and it > helps a lot to get smaller binaries, > and this should help with RAM size too, since if a page of a binary > contains mostly unused things and 1 symbol > which is actually used it will still get paged in. > > Can you perhaps start a new devel list thread about just this ? Maybe with > some binary size numbers for > some apps / libs build with and without these options? > It's pretty well documented in various articles, e.g.: https://wiki.wxwidgets.org/Reducing_Executable_Size It also covers how much difference -Os can make. > > 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. > > Actually ulimit -s is the *maximum* stack size, I'm pretty sure the stack > will start much smaller and > grow dynamically. So changing this is not saving any RAM and it will makes > apps which do have high > stack usage crash when they hit the new lower limit. Either way, it makes a noticeable difference to memory consumption on a very memory constrained system without any other obvious adverse effects.
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
