10:03 <geertu> arnd: Debian 9 on a 32 MiB system, even with swap, still has its issueis: "apt upgrade" or "apt install" hangs silently ater processing the list of packages.

10:03 <geertu> "apt list --upgradable" works, so I used that output to manually run "dpkg -i" on the packages downloaded on the 64 MiB RZ/A2 (which also needs swap over nfs to run "apt update", but completes "apt upgrade" fine).

10:03 <geertu> During "dpkg -i", I got several "Failed to reload daemon: Refusing to reload, not enough space available on /run/systemd. Currently, 10.4M are free, but a safety buffer of 16.0M is enforced.".

10:07 <arnd> geertu: I wonder if tmpfs has a hard limit in file system size based on total RAM or you could work around with a mount option. Putting /run on NFS instead of tmpfs is probably faster anyway if tmpfs just turns into swap

10:14 <geertu> arnd: I think it has such a limit. The 10.4M more or less matches the available memory reported by "free"

10:15 <geertu> And even with 1 GiB of swap over NFS, I see a few memory allocation failures in the log, order=1 and even order=0

10:27 <arnd> geertu: I suppose once you get into order -0 failures, the system can be considered dead because a lot of kernel code assumes this won't ever fail

10:30 <arnd> What I'm not sure about is whether this is just a result of bloat accumulating everywhere, or more of the kernel getting worse at dealing with oom

11:25 <geertu> arnd: indeed

13:33 <Xogium> about memory allocation and order 0 and 1… I managed that on a x86_64 machine

13:33 <Xogium> with 24 GB of ram

13:33 <Xogium> it ran for about a year and a half, and the memory fragmented too much

13:35 <Xogium> a good rebooot and everything was back in working order, pun intended

13:35 <Xogium> *reboot

13:37 <Xogium> it was down to the point I couldn't spawn tiny process like cat

13:38 <Xogium> note to self: don't leve a machine compiling things over and over and over running for over a year

13:40 <bencoh> why not though? :]

13:40 <Xogium> bencoh: why not what ?

13:40 <bencoh> ah, OOM

13:41 <Xogium> bencoh: nah not even OOM… Just memory getting too fragmented

13:41 <bencoh> yeah

13:41 <Xogium> it just failed to allocate even the tiniest bytes of memory

13:41 <bencoh> that's interesting actually

13:42 <Xogium> it left programs acting totally weirdly, I had build failures that didn't make any sort of sense

13:43 <Xogium> makes you wonder just in how much time memory fragmentation becomes a problem on a more idle system

13:45 <Xogium> but, I reckon it's like anything left unattended for a while. Things left without supervision too long tend to break, after all

13:46 <bencoh> I dunno, I've had linux systems run years without even worrying about the issue, so ... :)

13:46 <Xogium> I think if I had let it going for even a few more days it would have frozen the whole machine, because even things like ls and such would probably eventually fail

13:46 <bencoh> yeah

13:47 <Xogium> but do you compile entire OS with them ? What I was running was a buildroot autobuilder that built and built and built, and sent each result to upstream buildroot

13:48 <Xogium> nonstop

13:48 <bencoh> no, I was answering to the "more idle system" question

13:48 <Xogium> ah

13:49 <Xogium> yeah I suppose memory churn is different possibly on each architecture ?

13:49 <bencoh> modern kernels might tackle your issue with proactive compaction btw

13:49 <Xogium> oh this was a modern kernel

13:49 <Xogium> well

13:49 <Xogium> it was on 5.8 or 5.10, I forget which

13:50 <bencoh> less than 1.5~2yo?

13:50 <bencoh> probably older than the most recent patches then

13:50 <Xogium> ah, if you mean modern in that sense, sure

13:50 <Xogium> I thought of modern as anything that was like… I dunno, not ancient 3.x/4.x :D

13:51 <bencoh> https://lwn.net/Articles/817905/

13:51 <Xogium> y'know, I should try this again

13:52 <Xogium> just as a test, not submitting results in case it goes bad again

14:22 <geertu> The main reason to reboot my desktop machine is to fix graphics. After a while new window contents are no longer refreshed correctly (seen mostly with evince), and the display server needs to be restarted to fix that. Which I use as an apportunity to do a full reboot.

14:43 <milkylainen_> doesn't systemd have hard requirements on memory? Ie, bluntly refusing to operate?

14:46 <Xogium> hmm not sure. If it does, I never went low enough to notice

14:47 <milkylainen_> I might have missed the entire point of the question though. But I think systemd has a hard limit where it bluntly refuses.

15:00 <milkylainen_> Or maybe I'm just dreaming.

15:13 <geertu> milkylainen_: Yeah, "but a safety buffer of 16.0M is enforced."

15:13 <milkylainen_> geertu: *shrug*