On 18-08-19 15:25, Gordan Bobic wrote:
On Sun, Aug 18, 2019 at 2:06 PM Hans de Goede <hdego...@redhat.com 
<mailto:hdego...@redhat.com>> wrote:


    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> 
<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_ 
     > 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.:
It also covers how much difference -Os can make.

Interesting, thank you for that link.

     > 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.

Interesting unless I'm reading the manpage wrong, "ulimit -s" sets the maximum 
Maybe that also influences the initial sizing of the stack ?

Can someone who knows more about this shed some light on this? Is there a way 
to go with
a smaller initial stack-size without changing the maximum size?


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