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.:
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: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to