Re: Better interactivity in low-memory situations
This seems very reminiscent of what is often referred to as "swapping insanity", often in the context of MySQL. The root cause there is NUMA with memory allocation only happening on the node that requests the memory, resulting in the possibility of there being plenty of free memory on one node but the allocating node deciding to swap out instead of allocating far memory. I don't think there was ever a solution fielded, but the workaround was to set the memory heavy process up with numa round-robin allocation. This results in even allocation across the nodes, thus avoiding swapping, but it capitulates to the fact that half of the memory is always going to be twice as far away in terms of latency. I don't know if the underlying root cause is shared in this case (something less than clever in the way memory allocation is handled). On Mon, Aug 19, 2019 at 9:55 AM Florian Weimer wrote: > * Gordan Bobic: > > > That may be so, but this thread started off with memory pressure also > > being an issue for regular desktop x86 use. > > I think the problem there is that the system has sufficient reclaimable > memory, but cannot make that memory available to applications in a > timely fashion. > > Reducing compiled application footprint will only increase the amount of > reclaimable memory, probably not changing anything as far as the actual > problem is concerned. > > Thanks, > Florian > ___ 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
Re: Better interactivity in low-memory situations
On Sun, Aug 18, 2019 at 9:07 PM Kevin Kofler wrote: > Gordan Bobic wrote: > > Right, but is it better that _everything_ else suffers with more memory > > pressure for the handful of relatively infrequent use cases for which > > ulimit can be used to explicitly raise the limit? > > Well, as I wrote, a lower limit might actually make sense on ARM. But > modern > x86 computers have gigabytes of RAM, so 1 MiB is ridiculously small there. > So this would have to be an architecture-specific setting for ARM. That may be so, but this thread started off with memory pressure also being an issue for regular desktop x86 use. ___ 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
Re: Better interactivity in low-memory situations
On Sun, Aug 18, 2019 at 8:51 PM Kevin Kofler wrote: > Gordan Bobic wrote: > > 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. > > I've more than once had Java applications crash with a StackOverflowError > because Java has such a retarded 1 MiB default stack size independently of > the amount of available RAM. (You have to explicitly use the -Xss > parameter > to get more.) It happened at least once in Java code and at least once in > C++ code interfaced through JNI. > > So I don't think 1 MiB is a reasonable default stack size for > general-purpose computers, though it might make sense on ARM. > Right, but is it better that _everything_ else suffers with more memory pressure for the handful of relatively infrequent use cases for which ulimit can be used to explicitly raise the limit? ___ 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
Re: Better interactivity in low-memory situations
On Sun, Aug 18, 2019 at 2:33 PM Hans de Goede 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@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
Re: Better interactivity in low-memory situations
On Sun, Aug 18, 2019 at 2:06 PM Hans de Goede wrote: > Hi, > > On 18-08-19 13:33, Gordan Bobic wrote: > > On Sun, Aug 11, 2019 at 10:36 AM 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
Re: Better interactivity in low-memory situations
On Sun, Aug 11, 2019 at 10:36 AM 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: 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
