Re: Better interactivity in low-memory situations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Aug 18, 2019 at 2:33 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote:

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

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 stack-size.
Maybe that also influences the initial sizing of the stack ?

I believe it does. Or at least that is the only explanation I can come up with for the observation.
 

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?

It may be simpler to approach the question from the other side, i.e. is there anything that actually ever needs more than 1MB of stack space? If there is, I haven't seen it in the decade since I've been using this tweak with various Fedora derived distributions.


_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux